03/10/10 :: [MDE] From DSL to MOP [permalink]
Johan published a great summary of a somewhat old article from Markus Voelter: "Best Practices in Model Driven Development". I say somewhat old, because the article was written in 2005 and Markus's position may have evolved since that time. I'd like to take a moment to express how Metamodel Oriented Programming redefines the foundation of DSLs.
Sources for the language
I no longer think that Domain DSL make much sense. Domain experts rarely have the semantic precision that would allow supporting their work with a DSL. Note that technical people don't exhibit much more precision. Just look at the REST space and see how people "interpret" the semantics of a resource, four verbs and URI. Ok, maybe the problem is that REST is so poor semantically that they "have to" add their own semantics, but still.
Recommendation 1: build your language for the solution space, leave the problem space to creative expression.
Limit Expressiveness
On the contrary, I would argue that the problem of limited expressiveness is precisely the explosion of "interpretations" of semantics. Again, use REST as an example: everyone needed a query language. What happened? everyone created his/her own. It may not happen on the same scale in your organization, but it will happen enough to be a real pain.
Recommendation 2: Make your language as expressive as it is needed but not more
Notation, Notation, Notation
Text is beautiful. Do not mix the need for graphical visualization with the need for graphical design. Most often textual definitions can be converted (automatically) in graphics.
Recommendation 3: use graphical editors as rarely as you can. Prefer textual notations with graphical renditions
Viewpoints
The goal is not to have everyone express something, the goal is to build solutions fast. The design of the language must be driven by how fast you can translate requirements into a working solution. Take the example of BPMN. BPMN was designed to let a certain category of people express their view point. That's great. When it comes to create "executable BPMN definitions", well the little known secret is that developers stuff the definitions with tons of arcane, hard to debug, scripts. This is highly inefficient. From my own experience, it can take 3-5 times as much to write a solution using an executable BPMN engine than writing it in 3GL.
Recommendation 4: design the language for rapidly building solutions (from as few viewpoints as possible)
Partitioning
In MOP this best practice translates as rules that enable execution elements to control the lifecycle of other elements. The language needs to be one, however, you should restrict with precision the lifecycle operations a model element can invoke on another. I would not call that partitioning
Recommendation 5: understand with precision which model element control the lifecycle of other model elements
Evolution
This is a difficult topic, MOP doesn't necessary help here. However, because MOP forces you to think through the entire lifecycle of the model elements and the relationships between the model elements at the implementation level, you may end up needing far fewer evolutions. DSL focuses only on the associations between model elements, not there interelated lifecycles.
Recommendation 6: Think through the entire design of the language, especially the lifecycles
The fallacy of generic languages
We agree, yet, as you focus on the solution side, you should remain as generic as you can, what is wrong is the monadism of general purpose languages, not genericity per say.
Recommendation 7: Think polyadic programming languages
Learn from 3 GLs
I would say, learn from both 3GLs and DSL. This is what MOP is about, bringing cogency and polyadism together in one efficient formalism.
Recommendation 7: Design Cogent Polyadic languages
Who are the first class citizens?
You don't have to choose, this is the wrong choice. DSL forces you through that choice because second class citizens are created to implement the cogent aspects of the model. MOP focuses on first class citizens without the need of artificial model elements needed to express execution elements.
Recommendation 8: Avoid creating model elements to express execution semantics
Libraries (and Patterns)
I have mixed feelings about that one. Why would you create libraries and patterns in your DSL? They exist only because of the monadism of the general purpose languages. Programming Patterns would have never existed if programming languages were polyadic.
Recommendation 9: Rely on as few libraries and patterns as possible on top of your language, prefer a higher degree of polyadism
Teamwork support
Go Textual !!!!!!!
Recommendation 10: MOP is textual in nature, structure your language to facilitate teamwork and leverage all the source-based tools
Models Interpretation vs. Code Generation
The bad reputation of Code Generation is due to the lack of execution semantics in DSL, i.e. DSLs are not cogent. MOP languages facilitate the transformation (not generation) into general purpose languages because the execution semantics are half way there.
Recommendation 11: Prefer "transformation" to model interpretation or code generation
Don't modify generated code
Yes, but you can modify "transformed" code. Round-trip engineering in code generation can be very tricky. However, using a transformation paradigm in lieu of code generation make the round-tripping a lot easier.
Recommendation 12: You may use round-tripping safely when it makes sense, but avoid it if you can
I am not quite sure today, why the DSL community do not see how much simpler their life would be by making DSL cogents. I also don't see why the general purpose language guys keep annotating their language to death. They annotate it so much that they can't see the semantics behind their annotation. But, hey, what do I know? I am just a MOPer.