Yes folks, I’m at Jazoon currently. And while at it I thought I could persist my impressions in this blog. Why not share my notes with the world? After all, this is what blogging is all about – in a way at least.

The talk “Model-driven architecture with MDA“ was presented by two engineers from ergon AG. They presented their accumulated experiences from a real world project. While one can find loads of information about MDA as such, it was interesting to hear about hands-on experience. Since I got my own fair share of MDA stories and since those experiences made me somewhat reluctant to howl with the MDA-is-so-great wolves, I was keen to learn if it can be done right easily. A few things that I picked up:

• AndroMDA seems to like certain UML tools better than others. Magic Draw was used in the project presented because it was recommended by AndroMDA. I learned the same the hard way when we migrated from one modeling tool to the other. The XMI dialects can be quite different. Watch out for that! There’s a fair chance that you’ll have vendor lock-in there.
• Since AndroMDA uses the concept of “cartridges” (that’s what they call their plugins) the generated code can be based on any application framework. ergon generated code for Spring and Hibernate for example with the respective cartridges. Since those cartridges are extensible it should be easy, the said, to write your own.
• One major aspect of generating code is protecting those code sections you augmented yourself after generation. You don’t want that a subsequent generation run overwrites your own code. We used to have specially marked protected code sections the generator would not touch. According to the presenters AndroMDA seems to have an issue with this. It generates abstract superclass and dummy implementations for each abstract class. You’re then expected to fully implement the generated subclass. AndroMDA won’t touch those again. However, if your interface changes (resulting in a new abstract class) you have to push down those changes to the implementation class yourself. Or throw away the implementation class and have AndroMDA generate a new dummy implementation that satisfies the interface. Ugly and error-prone.
• ergon seem to advocate to “breed” a new kind of developer. They call them “modelers”. Hard-core code junkies like myself are likely to get bored with their job if they rarely need to touch code anymore – as promised with the MDA approach. At ergon the same developers that would have hand coded the application were used to model and generate the application. It was said that they (only?) still had fun because everything was so new to them.