05/06/09 :: [MOP] Implementation Elements [permalink]
The part that I like most about InfoQ is that there is always some great content or a pointer to some great content pretty much every day. Abel Avram wrote this great summary today on "Language Workbenches". He provides a pointer to the first public preview of the Intentional Software Domain Workbench (IDW).
Like Markus, I would advise anyone interested in DSLs to take a look at it. There is serious thinking behind this new product. Ironically they only show examples that I would qualify as part of Solution domains, not Problem domains. You know my position on that topic: it is more important to develop highly productive solution models rather than trying to involve the people that can define the problem in the solution construction. So I am yet to see Intentional Software showing a problem domain.
I was both impressed and disappointed by the demo. Impressed because they seem to have built a robust MDE tool with lots of great ideas and disappointed because like every other MDE framework it is based on an AST.. An abstract syntax assumes a MOF like M3 layer. This is true of openArchitectureWare, or JetBrain MPS as well. In other words, an AST based approach simply ignores the M3 level.
For me implementation elements are not just another part of the AST, they have rules and constraints that are somewhat harder/inefficient to define at the M2 level. This is where an M3 level comes into play. Ignoring M3 prevents the definition and reuse of standard implementation semantics such as an implementation type (procedural, orchestration-based, template-based...) and lifecycle definitions. The lack of an M3 layer basically treats implementation elements syntactically. It forces everyone to reinvent its own little syntax and rules. This is a degree of freedom that is not needed and that may endanger the very foundation of Model Driven Engineering, assuming that people finally understand that anemic DSL are just a toy and start taking advantage of implementation elements (of which a method is a particular case). In other words, freedom must be given at the metamodel definition level but implementation element semantics must be constrained to facilitate the creation of standard interpreters and compilers and contribute to the convergence of programming skills. What is needed today is not a syntax parsing framework but a framework that supports the design of "cogent DSLs" (as opposed to anemic). Cogent DSLs are the reason why we need textual DSLs, but an (anemic) textual DSL has hardly any benefit on its own, it brings nothing new.
I said before that UML has lost its original purpose and has become an M3 layer, I stand by that statement. Unfortunately, UML is no MAF. However we can illustrate how a Meta-Architecture-Framework could be used to enable cogent DSLs: as an M3 layer UML is somehow expressed in a backwards way (UML was never designed to sit at the M3 level). When someone defines a stereotype <<foo>> on an element of the UML metamodel (say a class), it really means that the metamodel element foo is of stereotype class (since foo itself is a type). This is how an M3 layer should be used, for example: I should be able to say this particular metamodel element (M2) behaves like a class (M3), a service, a resource, a message, an event... At that point, it becomes possible to infer the semantics of the implementation elements which become uniform across all DSLs. Having the ability to design syntax freely for a given implementation element will drive us to a wall. It will create an universe of micro-languages and drive a high level of inneficiency.
I am certain that the MDE pundits who marvel at textual DSLs will happily either ignore (as non classical) or reify implementation elements behind the basic principles, sorry, the classical principles of MDE, i.e implementation elements are just a bit more metadata and constraints. When I look at the market today it's clear that few vendors if any will take the time to develop a Meta-Architecture-Framework, but hey we can always dream.