MDA Skeptic - part 3: impact on code

A lot of emphasis has been put on the fact that MDA tools could be used to generate pattern code, straight from the model. The one thing that is puzzling me is that in a full MDA scenario this is useless. Patterns are a great way to clean your design, and to define the proper responsibilities to the components. But they do so having 2 good weapons.

• Readability: the code looks cleaner and clearer,


• Ease of (re)use: further evolutions are easier because the pattern structure defines the place where to work, when you need to add or change something.

They both are valueless in a MDA approach: the code is not written, but is generated so it won’t make a big difference if it’s cleaner or not, the edit point is in the Model, or in the Mapping, not in the generated code. Of course, generating the correct patterns would be fine in a one-shot MDA approach (which I tend to dislike, ‘cause will deviate from the model anyway), but the good point of MDA is exactly the one of keeping the model in sync with the code, the full MDA roundtrip.

We can probably expect specific MDA patterns to arise in this context, as long as MDA adoption gets wide enough, but design patterns (and architectural patterns as well) look too rooted in the traditional development process. If we move the focus on the definition of the model, then readability, and maintenance cost are no longer key factors, as – for example – performance might be. Possible candidates for being popular patterns in this new context are likely to be the Analysis Patterns collected by Fowler some years ago.

Tags: MDA, Model Driven Architecture, OOP, Design Patterns