While Model-Driven Engineering (MDE) is receiving more and more attention, the confusion is becoming bigger. Just look at the number of abbreviations starting with MD! Interesting discussions are going around about using UML or Domain-Specific Languages (DSL), triggered by some rumors of Microsoft Oslo. Methods & Tools recently published an article on the UML vs. DSL topic in which the authors conclude:
So what is the outlook for the industry? It’s our belief that as a basis for modelling for code generation, UML tools – in their current form – will gradually lose “market share” to DSLs: DSLs can be more direct, appealing and easier to use for a wider range of users. However, UML vendors, with their strong background in code generation approaches, can compete by adding a non-UML modelling and meta-modelling ’surface’. Combined with their tool’s existing UML features, this would make an attractive combination product for many companies.
I’m not going to add a view to this discussion, I want to start another discussion: why do we still generate code? In the quote above they talk about ‘modeling for code generation’, and that’s exactly what a lot of the current model-driven approaches are doing: transforming higher level models into lower level models until the model is expressed with source code.
In a panel discussion on the past & future of MDD at the recent MoDELS ‘08 conference in Toulouse, some of the panel members did touch this subject. In short they did state that if you specify a system using some language, which will be transformed in some other executable language, there often is a difference in computational models between these languages. Imagine, for example, the following scenario:
Model A -> Model B -> Source code
In most cases a difference exists between the underlying computational model of A, B and the source code, at least between two of them. In debugging such a system you need to understand all computational models AND the transformations between them. That’s quite difficult, in fact, it can be more difficult than debugging a system just written directly using the source code.
If we directly execute the model we can debug at the model level. What we need is a language which means something by itself, without a lot of transformations. One of the panel members even compared a visual model transformed into code with C macro’s. That’s maybe a bit overdone, but you get the picture.
So why not just execute the model directly, without complex transformations, thereby enabling debugging at the model level?