MDA/MDD: don’t round-trip!

In MDE life-cycle, round-trip engineering means ability to update a model based on source code reverse modeling. Funny practice: as the source code is issued from this model during the generation step, it’s a kind of “shoe is on the other foot”!
More precisely, round-tripping is a way to work indifferently on model or source code, whichever the easiest to use at any time we have to change something.  So let’s the idea growth to its zenith to see where we are going…

In MDA/MDD the source code is obtained (at least partly) from a generation step with the model as input. If model and source code were equivalents, many conclusions should come:

1. The source code is… the persistent form of the model?
   Don’t laugh. I know at least one very good tool that uses sources code as model persistence (eUML2). And Microsoft longtime DSL usage does act this way. It’s an efficient way to document source code, or at least to give a new perspective in source code understanding. And in another hand, maybe some programmers would be more efficient in designing their source code rather than programming it. But fact is that all we get is a tough technical model which speaks to developers only. Eventually. Even from an architectural standpoint this kind of model needs to be transformed in more focused models.
2. The reverse modeling operation is the exact reverse mirror of the generation operation?
   If source code is the persistent form of the model it means that the serialization operation implemented in the modeler product takes in charge the transformation model>source code. And by the way the modeler product necessarily implements the model>source code generation. If not (I mean source code is not a persistent form of the model, don’t get lost!), the development team has to produce generators… and reverse-generators. Better openness that in previous case as one can handle how source code is produced. But all this sounds rather… Not agile, see what I mean?
3. Modelers are developers?
   If model is code, it means that we handle code plumbing at model level. Means that model is a full conception of the code behind. Even if smartly hidden into modeling assistants (“Don’t model outside them!”), getting a business view in that model sounds like climbing the Everest without oxygen canister… Isn’t it?
4. Developers are modelers?
   If code is model, that means that developers may altogether produce models instead of code. Sounds great for them, as it is well-known that modeler is the next evolution step after developer in IT social progression!… But how do you trace and fix a performance problem from the model side? Wait… You just need a model debugger!
5. By the way, what is the purpose of MDA/MDD?
   Model is not code. A model is an abstraction, code isn’t(*). A modelization language (as UML) may be used to express architectural views, either technical or functional ones. The main reason to use modeling is to abstract technical plumbing aspects and focus on the ideas above. To focus on a way to organize user needs into something that we have a good and reasonable chance to get implemented into a program that runs smoothly and produces the expected results.

I think that coupling modeling and coding through round-trip twenty years ago in the first MDA enabled tools (like Together) is one of the main reasons why UML and premises have taken so much time to be fully adopted. Not speaking of MDA/MDD.

So please, don’t round-trip!

(*) In fact, source code is also a model… Of machine language instructions or equivalent, used to generate executable instructions through a compiler (cold or hot: it doesn’t change the point). But did you ever try to decompile machine code? I mean, not just for fun? ;D

Featured image taken from http://glenniba.com/