Model Transformation
I'm in Jamaica at the MoDELS 05 conference.
Yesterday I attended a workshop on model transformation, where a number of different techniques were presented. The organizers had asked all submitters to apply their technique to a standard example (the object-relational mapping) so it was quite easy to compare the different approaches. There were also some excellent discussions. Here's my distillation of key take-aways:
1) Most of the approaches modeled the tracing data (i.e. the mapping itself) in some way. Transformations created both the tracing data as well as the target model. Some of the approaches (e.g. triple graph grammars) used the tracing data generated by one application of the transformation as input into the next application.
2) Rules which use pattern matching was a common theme running through most (though not all) techniques. Placing priorities on rules was one way of controlling the order in which rules are processed. Some combined rules with imperative code, to put control structure around rules or to 'finish' off work done by a rule. Some techniques used constraint solvers to avoid writing any imperative code at all.
3) There was an interesting discussion about specifying and testing transformations. One could argue that a dedicated model transformation language, if it is any good, is high level enough not to require a separate specification. Even so, it's still necessary to validate that the transformation meets the business need: does it produce the expected results for designated example input models? So we need testing frameworks for delivering input models to a set of rules and checking the output is correct. How do we check the output is correct? It depends on what it is. If the model is executable, you can test its execution to see that it has the desired behavior. If not you can at least inspect it and check that it is well formed. One can also write well formedness constraints on the tracing model (see 1) and check that generated traces are well formed. This then led into a discussion about debugging transformation rules... here again the tracing data may be useful information, especially if the order in which rules have been fired, hence tracing information created, is also kept.
(An aside: In building DSL Tools we have been faced with the issue of specifying code generators, which are expressed as text templates. An effective way of specifying them, we have found, is to describe the behavior of the generated code for various combinations of inputs.)
4) Another interesting discussion emerged around the topic of bidirectional mappings and model management. Suppose we have two models where one is not fully generated from the other - they are both edited directly in some way. The goal is then to keep them consistent and help the user bring them back to consistency, and there would probably need to be UI specific to the particular transformation in question to do this. Again, tracing information seems important in this scenario. But now consider a team scenario with multiple models and multiple mappings between them. Different team members make changes to models, checking them into source control. How do you go about keeping all models consistent with one another across the mappings? What are the steps a developer must take when they check in? When dealing with a large code base through source control, you soon learn to use diff and merge tools and also soon learn that there are different levels of consistency: will the code build? does it run all tests? does it meet all scenarios? I think it's a similar situation with models. We need diff and merge tools with models, and, they have to be domain specific, just like the languages. We need to start considering what the different levels of consistency are: are there any unresolved cross references between model elements? are the models well-formed? are the mappings between models consistent?
5) Finally there was a brief discussion about diagrams and diagram layout. The point being that if you run a transformation to create a new model, then what about creating and laying out the diagram to go with that model (assuming a graphical modeling language here)? And what about getting that layout to be a transformation of the layout of the source model?
Interesting, uh? Well I thought so, at least.