Thoughts on Migrating Model-Driven Solutions between Tools

This week I was at a customer who started MDD a couple of years ago. They started with oAW 3.x and at some point migrated to oAW 4.x, using the Classic mode. This means that the meta model was implemented as Java classes. Because the decided to generate from UML, the meta classes were subclasses of the UML 1.x meta model implemented in Java that shipped with oAW classic.

The model defines the core data structures of a large scientific instrument, and it serve as a data exchange layer between systems implemented in several programming languages. Consequently, they have code generators for seven different target languages, i.e. they have put quite a bit of effort into the generators. The meta model structure is reasonably simple, but the behaviour, or derived attributes if you will, implemented in Java is quite non trivial.

Now they decided to migrate to the most current oAW, i.e. using EMF for the meta model and models, and Xtend for the derived behaviour. Consequently, all the meta classes implemented as subclasses of UML 1.x classes don't work anymore. Generally, the behaviour implemented in Java is obsolete and cannot be directly reused. A manual migration of the behaviour from Java to Xtend (or to whatever other platform) is required. This is a lot of work - almost prohibitive!

So what can we do to avoid situations like these?

There is no simple solution. Dependencies on tools, no matter which kinds of tools, are always a problem. If you wanted to migrate your system from one database/middleware/UI framework to another, this is also a lot of work. What can we do specifically in MDD tools to tackel this problem? I think there are a couple of things that are a good starting point:

Instead of writing the code generators directly against the UML meta model, you should introduce an intermediate domain specific layer. Code generators are written against this domain specific meta model, and a model-to-model transformation transforms the profiled UML model to the domain specific meta model. This has several benefits: generators become simpler because the are written against a simpler meta model. Simpler generators are easier to migrate. The complexity of handling UML (they used a couple of non-trivial conventions) is encapsulated in the one M2M transformation instead of being repeated into seven code generators. Also, a migration from UML 1 to 2 (or to a real DSL, throwing away UML) would be simpler, because the differences would all be handled in one single place. No change to the code generstors required.


As a second point, you should use declarative approaches wherever possible. Things like validations, scopes, type systems etc. should not be implemented in "procedural" code. Turing complete, procedural code is hard to "understand" with a tool (other than a compiler) and hence is complex to transform into another representation when you want to migrate the code. The more declarative, restricted and structured such descriptions are, the easier it is to work with them. This is of course the whole point about models in the first place! So maybe I should say it differntly: make sure that as many aspects of meta models, validations, scopes, generators and transformations are themselves described as a model! In oAW 3.x/Classic this is clearly not the case - it is the case to a larger degree (not enough!) with more current versions of Eclipse Modeling and oAW.


Finally, assuming you use models for all these things, make sure it is models based on the same tools/formalisms as your application models. This makes them "just another model" which you can (relatively) easily process in a migration with the tools you are working with anyway. In tools like MPS and Intentional, all aspects of DSLs are defined with models expressed in other MPS/Intentional DSLs. It is turtles all the way down :-)

So what do I take away from this: First, migrations are always hard, also in case of MDD tools. They are especially hard if the effort is put into the generators (for multiple platforms) and not so much into the models (note that we actually added an intermediate domain-specific meta model now; introducing this is just two or three days of work). The second takeaway is that we need to enhance tools such as Xtext
(or EMF in general) to describe more aspects of DSLs as models. Validations, scopes and type systems, as well as model navigation and queries ("give me all types of all public attributes of all classes in this file") are important candidates. There will of course always remain some aspects that need to be described with turing-complete implementation code. But by keeping this to a minimum, the tool lock-in and migration effort is minimized.  permalink