When talking about Model Driven Development (MDD), code generation and related technologies, the key terms, its meanings and usage could not be clear enough to the involved audience due to our different backgrounds and the use of overloaded terms in several specific jargons.
A good way to avoid such confusion is to make explicit a short clear definition of the terms used.
Following this idea, today I want to share the Conceptual Map I traditionally use to explain the areas involved in code generation. This map helps me to explain how more complex interactions and natural dependences and properties arise in this domain. See embedded video.
We will start considering MDD using two orthogonal dimensions:
- Types/Classes vs Instances &
- Two levels of abstraction: Programs/code (technology dependent, concrete) vs Models (technology independent, abstract).
- Model: A description of the problem to be solved.
- Metamodel: A type description for providing the modeling language.
- Template: A pattern representation of the code you want to create.
- Transformation: Application of an algorithm to transform one or more models in one o more outputs.
- Output: Your target asset: source code, doc or models again.
- Mappings = Template to Metamodel item bindings
- Architecture Know How = Mappings + Templates (embedding best practices and patterns)
- Business Know How = Metamodel + Model
- Model Checker = Validation of Model with respect to Metamodel
- Generator = Transformation(Templates, Mappings, Model) –> Output
A pair of properties to mention.
- Metamodel: Quite stable once developed.
- Model: Stable till the business change (requirements change).
- Template: Stable till not changing or evolving the technology (2-3 years cycle?).
- Transformation: Impacted by technology or metamodel changes.
- Output (Source code): Regenerated as needed. Discardable.
- Metamodel: Not dependent of third parties.
- Model: Altered if metamodel changes.
- Template: Not dependent of third parties (just the technology).
- Transformation: Impacted by template changes, mapping changes and metamodel changes.
- Output (Source code): Impacted by everything. Regeneration is a good property as seen before. But now is a necessity.
Changes in the formers will cascade to the latter.
Strong Separation of Concerns & skills
Apart of the classical advantages provided by MDD approaches such as quality, productivity, time to market, & technology independence; one of the good properties no so times recalled is the strong separation of skills that this method of software engineering provides:
- Business analyst can concentrate efforts in using modeling editors to describe the business and provide feedback to enhance metamodels (when needed)
- On the other side, Software Architects and technology gurus can concentrate in tuning the technical architecture to achieve the most performing implementations they can provide.
One you achieve this stage, you can start thinking of reusing and evolving your business models and architectures at speeds that most of traditional SW developers never seen before.
There is one famous quote from Grady Booch saying:
“The entire history of software engineering is one of rising levels of abstraction (abstraction is the primary way we as humans deal with complexity).” Grady Booch
As many others, I think that MDD is the next step to adopt in such direction. When it will happen globally is just a question of achieving the critical mass:
- having good enough tools,
- and having practitioners enough and success cases to prove the value in the “not so new” way of working.
I’m optimistic about it. We are in the way and getting speed…