Saturday, November 21, 2009

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.
Comments: Post a Comment

<< Home

back to

This is Markus Voelter's Blog. It is not intended as a replacement for my regular web site, but rather as a companion that contains ideas, thoughts and loose ends.

December 2005 / January 2006 / February 2006 / March 2006 / April 2006 / May 2006 / June 2006 / July 2006 / August 2006 / September 2006 / October 2006 / November 2006 / December 2006 / February 2007 / March 2007 / April 2007 / May 2007 / June 2007 / July 2007 / September 2007 / October 2007 / November 2007 / December 2007 / January 2008 / February 2008 / March 2008 / April 2008 / May 2008 / June 2008 / July 2008 / August 2008 / September 2008 / October 2008 / November 2008 / December 2008 / January 2009 / February 2009 / March 2009 / April 2009 / May 2009 / June 2009 / July 2009 / August 2009 / September 2009 / October 2009 / November 2009 / December 2009 / January 2010 / February 2010 / April 2010 / May 2010 / June 2010 / July 2010 / August 2010 / September 2010 / October 2010 / November 2010 / December 2010 / January 2011 / March 2011 / April 2011 / May 2011 / June 2011 / July 2011 / October 2011 / November 2011 / December 2011 / January 2012 / February 2012 / October 2012 / January 2013 /

You can get an atom feed for this blog.