Another classification of transformations

Different kinds of transformation

Rafael started an interesting discussion about the mutual interest of various kinds of model transformations:

In a previous post I proposed a first classification of transformations:

  1. Code to Model Transformations (C2M)
  2. Model to Model Transformations (M2M)
  3. Model to Code Transformations (M2C)

Here I would also like to introduce another classification, quite orthogonal to the previous one and however very important:

  1. Transformations executed at software development/production time
  2. Transformations executed at software maintenance/modernization time
  3. Transformations executed at software operation/execution time

These three kinds of transformations have very different properties.

MDSD (Model Driven Software Development) is a special case of MDE (Model Driven Engineering) where the transformations executed are mainly M2C transformations executed at software/development time.

This entry was posted in MDE, MDRE, MDSD, Transformation. Bookmark the permalink.

8 Responses to Another classification of transformations

  1. Jean, I think that it is one of the most important transformation classifications for MDE practitioners, as it actually says something about application domain/system life-cycle. Current mainstream view is that MDE is limited to software engineering and code generation. MDE is one of competence areas in our company and we find this view very limiting. In fact we also found good opportunities for MDE outside of software engineering. For this I would like to share en example.

    I am currently involved in an MDE/DSM project that targets analysis phase in a product’s lifecycle. The goal is to assist a large industrial company to respond to a potential client with a product proposal. The challenge here is to maximize reuse of existing SW/HW parts and come up (in *short* time) with such a product configuration that requires minimum client specific development. The underlying business process consumes cost and parts models (maintained in another department), analyses configurations (essentially M2M in-place transformation, but will be realized as M2T due to used language workbench). Naturally, no code is generated. The output is a contribution to product price/cost and capabilities estimates. This output has definite added value to the company, because it influences the purchase decision of client and earnings of the company (think about errors in cost estimates of the product development). Only when the client signed the purchase contract (thanks to this business process), will software engineering begin. (This also shows that Code is not the only added value.)

    • jbezivin says:

      Andriy,

      These are very important remarks. I am convinced like you that the most important applications of MDE are yet to come and that they will probably be beyond the strict limits of software engineering. As you say, models may be quite useful in situations where no code is generated.

      Thanks for noticing that we need new classifications of
      transformations. Until now we have mainly seen classifications of
      transformation languages, but this is not the problem.

      Your example is quite interesting. MDE is typically an application-driven area. We will learn from innovative and imaginative new applications of MDE. Originality is important here to explore new frontiers in practices.

  2. Jean/Rafael,
    In my opinion, model transformations are under-used in the MDE arena. Most people still think that models are for capturing your system architecture and/or business logic and then used to guide your implementation. In this sense, M2T transformations are the key ingredients and M2M are intermediate elements. However, models can (and should) be used for many other things.

    For example, there are several groups actively working now on the analysis of performance and reliability features of systems, right from their high-level models (see, e.g., the very interesting works by Cortellessa and his group at L’Aquila, or by Dorina Petriu at Carleton University). They amake heavy use of M2M transformations to transform UML models to models that existing commercial tools can understand and analyze. Similarly there are other groups that define M2M transformations between high-level models of the system for other interesting analysis (simulations, metrication, etc.).

    In this respect, I full agree with Jean and Andriy that driving code generation is one of the usages of models, but it is not the only one. This is the difference between MDD and MDE: MDE encompasses many other activities required to accomplish full software engineering, beyond software development. And we cannot neglect these other activities. On the contrary, I think that they should be fully adopted in the design and development of any serious software application, as it happens in the rest of the engineering disciplines: imagine civil architects or avionics engineers not using any tool to simulate his or her designs, analyze their properties (performance, resource consumption, expected max workload, etc.). Even hardware architects and designers run plenty of tesis and analysis checks on their designs before generating their chips of PCBs. And M2M and T2M transformations are essential for achieving these activities in the software engineering design! So let’s don’t underestimate them, please…

    Sincerely,
    Antonio Vallecillo.

    PS. Bran Selic, back in 2003 described the potential roles of Models in MDE (see below). They nicely fit with the ones that Jean just described.

    Usefulness of models [B. Selic, 2003]:

    A) Describe the system
    — Structure, behaviour, …
    — Separate concepts at different conceptual levels
    — Communicate with stakeholders
    B) Understand the system
    — If existing (legacy applications)
    C) Validate the model
    –Detect errors and omissions in design ASAP
    — Mistakes are cheaper at this stage
    — Prototype the system (execution of the model)
    — Formal analysis of system properties
    D) Drive implementation
    — Code skeleton and templates, complete programs
    ============

    • jbezivin says:

      Antonio,

      The quote from Bran Selic is quite interesting.

      I agree with your statement that transformations are important, all of them (M2C, C2M, M2M).

      Any DSL or MDE approach has to work on two feet: metamodels and transformations.
      Presenting a DSL approach without a well equipped transformation layer seems to me missing the boat.

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

  4. Sergejs Kozlovics says:

    I’m currently writing my PhD thesis, and I need all three types of transformations. I recommend to call them as follows:
    * “Transformations executed at software development/production time” => production-time transformations;
    * “Transformations executed at software maintenance/modernization time” => migration transformations;
    * “Transformations executed at software operation/execution time” => runtime transformations.

    By the way, in our tool-building platform GRAF (developed at Institute of Mathematics and Computer Science, University of Latvia, where I work), we use the last two types of transformations. [NB: GRAF is more like a pilot-project, but it was used to develop a graphical ontology editor OWLGrEd (http://owlgred.lumii.lv/), and several other tools.]

    • Jean Bezivin says:

      I am not completely sure the term “migration transformation” is completely adequate.

      More important, one of the weak points of the classification I proposed above: “1) Transformations executed at software development/production time 2) Transformations executed at software maintenance/modernization time 3) Transformations executed at software operation/execution time”, is that it was suggested when we still believed MDE was an exclusive part of software engineering. Many recent studies show that this vision was reductive and much too narrow. This hypothesis is probably wrong. As a consequence, the taxonomy of transformations proposed above should at least be revisited with what we know now. It looks a bit deprecated.

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