About model transformations

Model Transformations are essential

Some recent Twitter discussions triggered by the interview of Steven Kelly by Angelo Hulshout are interesting:

Rafael Chaves supports the idea that “the only model transformation that really matters is from original model into code”:

I do not agree with this idea.  In classical MDE we usually distinguish three different kinds of transformations:

  1. Code to Model
  2. Model to Model
  3. Model to Code

The most popular transformation is of type 3. This is sometimes called Model2Text or MOF2Text and typically allows to generate Java code from UML models. More generally these kinds of transformations have been heavily used in MDD for software artefact generation from abstract models. The source model conforms to a given metamodel (like the UML metamodel) and the target text conforms to a given grammar (like the Java grammar). There is an Eclipse M2T project.

But transformations of type 2 called M2M are central. The Eclipse M2M project proposes for example QVT and ATL but there are plenty of other possibilities. There are many examples of such transformations, for example in the ATL transformation zoo. In these M2M transformations, there is usually at least one source metamodel and one target metamodel, usually different.

The less known transformations are of type 1 sometimes called Text2Model. They are usually used in reverse engineering of legacy code in projects like the Eclipse MoDisco project. One example is the extraction of Java models from Java code. In MoDisco there is an open source Java metamodel of excellent quality that is quite close to the Java grammar. But one could imagine also directly extracting for example business rules from a Java program by using a Business rule metamodel. Alternatively another solution would be to use a Java.code to Java.model C2M transformation, and then a Java.model to BusinessRule.model M2M transformation. Usually C2M transformations are more expansive to develop than M2M transformations.

So I believe that all three categories of transformations are equally important. M2C and C2M transformations involve one metamodel and a grammar while M2M transformations involve two metamodels.

Similarly to M2C and C2M transformations, we could also have M2X and X2M transformations where grammars would be replaced by XML schemas.  Following the same idea, we could also envision M2DB and DB2M transformations where grammars would be replaced by Data Base schemas. All these native transformations would be quite useful, since they could be used with common M2M transformations.

This entry was posted in Metamodeling, Models, Transformation, Uncategorized. Bookmark the permalink.

10 Responses to About model transformations

  1. Hi Jean,

    (BTW, your blog is a must read for anyone interested in MDD and UML – love your posts on the OMG history)

    Interesting post. It is hard for me to agree that the 3 kinds of transformations have equal value though.

    M2T leads to running code – hard to question the value of this. IMO, it is the main use case for model transformations, well above the other kinds of transformations.

    M2M, as I wrote in a follow-up tweet, may make sense in some scenarios where intermediate formats are required, or for weaving models, but the real value for end users comes from the fact that they are eventually followed by a M2T transformation, which again leads us to actual running code.

    Text-to-model transformations might be useful if the text is actually in some specialized DSL (like the examples you gave about XML schema and DB schema), in other words, as a source for automatic creation of models based on external (often legacy) formats. Sure, that can be useful in modernization cases, but that is the exceptional scenario – in the happy path, models are created manually using true modeling languages, and transformations occur towards producing actual executable artifacts.

    I take an issue with the example you gave on extracting business logic from Java though – Java code deals with too many different concerns for tools to be able to make sense of it. Heck, even programmers may have a hard time extracting business logic from a Java code base (I guess you can tell I am a detractor of reverse engineering).

    Thanks for starting this discussion. Cheers,

    Rafael

    • jbezivin says:

      Rafael,

      Interesting discussion.

      I agree that most M2M transformations will be followed by a M2C transformation to generate the final code.
      More generally, what we see frequently are chains of transformations, with possibly one C2M, several M2M and one M2C transformation.
      This is for example what we have in interoperability/integration situations, but I agree this is not MDD, ist is more general MDE.

      On the issue of reverse engineering, I understand your argument that it is difficult in general to extract business rules from Java programs.
      But in specific contexts the situation may be quite different.
      For example I know of one insurance company where the real documentation on the rules of the insurance policy management have been maintained directly in the Java code. The most reliable information on the company business rules is given by the source code of the Java programs. This is a special case obviously, but these situations do exist. In general however your argument make sense.

  2. I think that the added value does not lie in mechanical process of code generation, but in creative problem solving proceeding it. We all know that due to growing complexity of the systems we build, this problem solving had to be raised from code to more abstract models. This means that added value lies by the user on the modeling side.

    Single uninterrupted (by humans) transformation step (be it a single M2C or a transformation chain tailed by M2C – it does not matter as it is implementation detail) is only feasible for relatively simple engineering problems. I am aware of very impressive experiences of MetaCase and myself is a user and promoter of their product. However, it is crucial to realize that their success stories deal with repeatable development of *configuration* nature. In other words, there is no new software created (but new systems). All creative work has been already (or will be) put into components and frameworks used by code generator.

    I think it is not difficult to see that modern software engineering is not limited to configuration. Moreover, a typical system development is not a one step process. In contrary it is a multi-step and concurrent process, in which added value is created by multiple individuals at different phases of system life-cycle (for an example see my comment here: http://tinyurl.com/2foywor) or at different levels of abstraction. It is only natural that in such context, MDE deals with models mostly. They (models) hold added value and M2M transformations help semantically connect them leading towards code generators.

    Actually in my experience, all conceptually non-trivial processes have been automated by M2M transformations (admittedly, M2M transformations also do simple things like format translations). And I tend to keep code generators real simple.

    It is fair to admit that it is possible to implement some types of M2M transformations using M2T pattern as follows: generate external intermediate model representation and import it back into a tool. One problem is that this introduces accidental complexity both to MDE developers and more importantly to end users (that have to do mindless generate/import routine, sometimes complicated by model merge). Another problem is that this M2T workaround does not work for in-place M2M transformation, of which application examples are: model optimization, model layout, model interpretation and in general any repeatable model manipulation.

    In conclusion, I would like to stress that this comment is not meant to belittle code generation or M2C/M2T transformations (it is even stupid to deny their added value). I commented to defend M2M, which is getting unfair harsh treatment as DSM is gaining in popularity (rightfully IMHO).

    • Hi Andriy,

      I am not that familiar with MetaEdit+, but MDD in general is not about configuration only, and my comments were about MDD, not DSM/MetaEdit+ (even if in context of Steven’s interview). IOW, I fully agree and understand that the “added value lies by the user on the modeling side” (assuming that by user, here, you mean developer – the development tool user). That is a core value of MDD.

      I wrote a much longer comment on this issue and posted it on my blog:

      http://abstratt.com/blog/2010/11/21/on-model-to-model-transformations/

      Cheers,

      Rafael

    • Steven Kelly says:

      Andriy,

      Thanks for the nice words about MetaEdit+. Just one clarification: our customers are definitely not doing “just configuration”. It’s real code generation, new software is being produced.

      Krzysztof Czarnecki put it well in his book on Generative Programming: a feature model, configuration system etc. leads only to a finite number of possible products, but a Domain-Specific Modeling language leads to an infinite number of possible products.

      Of course, at the deepest level there is no difference between code and data, software and configuration – it’s all ones and zeroes in the end, both in the form in which we store the statements that make up our program, whether graphical or textual, and in the form in which it is executed by the CPU. But I think we all have a shared understanding of what is a good example of code, and what is configuration – and the MetaEdit+ cases are overwhelmingly generating code.

      • Steven,

        W.r.t. “configuration” I admit that my choice of words was not very precise. What I meant to say is that MetaEdit+ applications with highest productivity gains, generate new software that *heavily reuses* underlying components and frameworks (this idea is also supported by MetaCase own diagrams explaining MetaEdit+ and my own experience as well). In other words, a large part of software must already exist in reusable form. And indeed, an infinite number of products is possible if DSL allows it.

  3. Pingback: On model-to-model transformations | abstratt: news from the front

  4. Jim Steel says:

    A number of my systems are now running generically, without ever generating code. This is especially common when the things being modelled are domain concepts rather than software artifacts. This is (IMHO) one of the key areas where MDE stretches beyond what is spoken about by MDA. With this approach, T2M and M2M transformations are more and more important. (Which is not to say that T2M and M2M are not also important inside MDA).

  5. Pingback: » On model-to-model transformations

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s