IT Modernization < V. Hanniet

software model driven approaches

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

18 comments on “MDA/MDD: don’t round-trip!

  1. vhanniet

    Better formulation for conclusion by @seidewitz on twitter: “Ever try to change compiled code, decompile it and expect to work on that again?”

  2. Marco Brambilla

    Hello Vincent,
    I deeply appreciate your post. I think it is time to make clear that advocating mdoel-driven methods does not mean to advocate for round tripping in transformations. Being a MDD adept myself, you can count me in as a first subscriber of your appeal.
    Let me clarify my opinion on the five statements you list (1 to 5) in your post: I see them as the naive reasons why a superficial MDD practitioner could opt for accepting model transformation roundtripping. I’m not sure the current one was the original phrasing of the post, but the whole point stands in the “IF” that you now highlighted (in orange). That’s why I would state explicitly that these are the wrong reasons that would bring to the wrong conclusion that round-tripping is fine.

    A good way to avoid round tripping is to force designers and developers to apply the manual changes that once would have been applied to the generated code directly at the modeling level. For instance, by supporting plugins and new concept definition at the modeling level. And, since we know that sometimes custom code or business logic is needed, also this should be allowed at a phase preceding the code generation.

  3. vhanniet

    You are perfectly right: after reading your comment on twitter I changed some phrasing and words in my post when I understood that my “ironical style” could be misunderstood.
    Thanks for your support.

    I will post more on MDA/MDD good practices.

  4. TY

    Excellent thinking! follow the clues, the reasoning, of itself, may be to lead to some challenges for some thing which seems been believed without a shadow of doubt…

    • vhanniet

      @TY: thanks for reading between the lines. One more post will come for each inter-line, one day ;D

  5. TY

    Hi, Vhanniet,
    your conclusion is, in brief, “Model is not code” and we should not be “coupling modeling and coding through round-trip”. right?

    • vhanniet

      Hi TY!
      In brief: 1) Model is not code, 2) Code may be (partly) generated from models, 3) Code may be reverse-modelized but this usage is not appropriate in MDA/MDD

  6. Pingback: Transformation between Models and Code: Can Be or Not Can Be, That is the Question « THINK IN MODELS

  7. modelpractice

    Can’t see the ‘either or’ in Round Trip vs Model Driven.

    There is modeling on the macro level as well as on the micro level. For the latter Round Trip is ok. Isn’t it?

    • vhanniet

      Sure, micro level round-trip works fine and is useful in some cases. It’s even a must in ADM modernization projects.
      I just say in this post that, trying to keep your words, “micro level round-trip is not suitable for MDA because MDA is a matter of macro level design”.

  8. Pingback: MDA/MDD: Model is not code!? « Vincent Hanniet * IT Modernization

  9. Pingback: The Sustainable MDA Manifesto: 1st draft « Vincent Hanniet * IT Modernization

  10. jean-loup comeliau

    Agreed, round-trips are a hassle. The resulting model polymorphism (model on one side, generated code supposed to concretize the model on the other side), is one of the reasons why model interpretation is an interesting MDD alternative to code. No round-trip needed then, since there is no overlapping between code and model. The only code needed in this case addresses needs outside the model, and therefore never overlaps with the model. Instead of generating code, you embed the model together with an interpretation engine at deployment time. Code cohabitates consistently with the model without interfering in the development process.

    • vhanniet

      Hi Jean-Loup,
      I think that cohabitation at execution time between embedded handwritten code and interpreted model is secured only if the development framework doesn’t let the developer make use of any executable object used by the interpreter (reading doesn’t count). In that case the handwritten code scope must be very poor, isn’t it ?…

      • jean-loup comeliau

        Not sure I’m following you… What do you mean by executable objects? If executable objects are instances of the model, the provided complementary code does make use of them without compromising security at all (updates included) . Code is handwritten, yes, but still tight to the development framework (by inheritance, for example). In this case, code is invoked on-the-fly by the development framework and is there to specialize the dynamic aspects of the application: data filtering, business rules, UI behavior, look&feel, etc. But maybe am I missing your point, here…

        • vhanniet

          OK, that was my point. If handwritten code may call core components, how do you manage bugs without doing a kind of roundtrip? Let’s say there is an unexpected UI behavior: does it come from the handwritten added code, or from the model, or from a bug in the model interpreter?

  11. jean-loup comeliau

    It all comes down to using an external library, which you do anyway most of the time (for the UI graphical layer, for example) doesn’t it? And of course, debugging tools (stacks, breakpoints…) will help.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s


This entry was posted on 20/04/2011 by in MDD / MDA, Modeling, Reverse modeling and tagged , , , .

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 187 other followers

Creative Commons License
IT Modernization < V. Hanniet by Vincent Hanniet is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.