One of the projects I’ve been working on recently is a large web application designed using MDA (Model-Driven Architecture). Now I confess that my Java experience lags at least a decade behind my C experience, but I feel that I’ve worked with the language long enough to have a reasonably meaningful opinion on things Java related. So I thought I’d write a few notes about my experience in case other people were considering following this path.

The project in question makes use of AndroMDA to derive a large amount of generated code from UML diagrams created using a suitable tool. Now here comes the first flaw in the plan: while AndroMDA is an open-source project, it appears that the only tool fully supported is MagicDraw which is a commercial tool, costing several hundred euros per copy. So by using a tool such as this, you’ve immediately raised the entry barrier high enough to prevent the hobbyist developers from working on your project in their spare time.

Initially we spent some time looking into whether ArgoUML would be suitable replacement, given that it was the only open-source alternative that came close to having full coverage in the AndroMDA compatibility matrix. Sadly, dialogue with the ArgoUML guys revealed the fact that MagicDraw doesn’t produce proper UML 1.4 standard output, and any workarounds would be reasonably non-trivial. This was pretty much the final nail in the coffin for being able to use anything other than MagicDraw to work on this project.

So at the moment we’re stuck with the requirement of having to use a commercial tool on an open-source project which is distinctly sub-optimal. However, the story gets better: AndroMDA works with UML 1.4 whereas newer versions of MagicDraw only support UML 2.0. At the time of writing, the latest version of MagicDraw available is version 16, whereas the last version supporting UML 1.4 is version 9.5. You can therefore probably imagine that a large amount of bugs have been fixed between versions 9.5 and 16, and I’m pleased to say that I’ve probably encountered most of them. If you are using MagicDraw 9.5, please don’t ever try to copy and paste objects from one model to another, because you’ll find that none of the object metadata comes with it and so you have to add it by hand anyway. Oh and as for importing the same objects from an existing XMI file, forget it…

Once you’ve spent several hours of wrestling with MagicDraw to make your changes, the next step is to run the resulting file back through AndroMDA in order to generate the template code. Alas this is where the AndroMDA code generator demonstrates its extreme lack of speed: on a reasonably sized MagicDraw project, it would take in the region of 3-5 minutes per module to validate the model and generate the code. I hope therefore that it is therefore obvious to the reader that making a minor change to a core object in a project of nearly 30 modules is an extremely time-consuming exercise, and of course if you happen to make a mistake then you need to regenerate the code on each attempt.

And finally, the biggest hurdle we experienced working with MagicDraw is working on a separate code branch. Merging selected features from one MagicDraw project to another is practically impossible due to the bugs mentioned above. At one point we ended up trying to diff two XMI files, but even that failed due to the way MagicDraw works. Every object within the MagicDraw project has a timestamp, and so altering any object (even if the change is reverted) will update the timestamp of any objects within the object hierarchy. And so you find that any diffs between two branches is virtually incomprehensible, and impossible to review in the same way that you can view a code diff attached to email.

To summarise, the entire AndroMDA/MagicDraw experience has not been a particularly good one for us. There have been numerous issues with both the tools themselves, and using them to implement the workflow required for a typical open source project. So in the meantime folks, please keep well away.