language parallax

I had several books from Amazon arrive while I was out last week. The first one I opened was “Model-Driven Software Development” by Thomas Stahl and Markus Voelter, published in 2006. The book has a website at www.mdsd-book.org.

I’ve only read 2 chapters so far: 1 and 10. Chapter 10 was actually written by Simon Helsen (see his personal page).

Chapter 10 is model to model transformation languages, and QVT in particular. This is the first time I’ve heard of the QVT initiative. Better late than never, I suppose. Model to model transformation languages is a large piece of what I want this dissertation to be about.

Section 10.2 is a list of requirements that any M2M language must have:

• The ability to look up what other transformation rules have calculated. Exposing the runtime footprint of a transformation execution.
• An identification mechanism on the target model to avoid adding elements to the target model in later runs.
• In the case where the target exists prior to the establishment of the transorm/relation, the ability to change target model just enough to make the relation hold
• The ability to run impact analysis on the transformation rules, in order to facilitate fast incremental runs.
• The ability to specify where in the target model controlled changes are permitted. Such changes might be the details of platform-specific implementation.
• The target model elements should be constructed incrementally. (I’m not sure I follow the motivation here.)
• Bidirectionality. Though this is contentious and the author feels that this is not necessary or even possible.

Which is fantastic. I think I finally am fairly current with a field of active interest AND I disagree with what one prominent book on the subject suggests. At this point I don’t have much other than “gut feeling” as an experienced software engineer to convince me of my opinion, but hopefully the next year will give me a little more to go on.

A couple of quotes regarding bidirectionality:

It would be difficult to use in practice, as changes in both source and target model can easily oscillate in an unexpected and uncontrolled manner.

Then later regarding the idea of View:

If the view needs to be editable, we bump into the bidirectional transformation requirement and its problematic consequences again.

This is the first time I’ve encountered anyone explicitly tying those two things together. I’ve been looking for this for a while, as editable “views” are something I’m very interested in implementing.

Elsewhere in the book is a reference to the “model bus” in the MDDi project. The reference suggests that this is “model-synchronized” as opposed to “model-driven”, but I’m not seeing a whole lot on that point at their site.

A late passage in chapter 10 speaks to the difficulty in getting m2m transformation into the mainstream:

We also believe that M2M transformation development will only be able to take off when M2M development environments have become available and are as good as modern programming language IDEs. However, this requires sophisticated tools with intelligent editors and advanced debugging facilities. Considering the fact that at the time of writing hardly any QVT tools are on the market in the first place, we are not anticipating QVT transformation writing to become a mainstream activity in the near future. Moreover, the lack of one standardized QVT language is a further hindrance for the acceptance and usage of QVT-style M2M transformation writing.