INTERNATIONAL CONFERENCE ON MODEL TRANSFORMATION (ICMT 2011)

ICMT 2011 in Zurich in 2011

Co-located with TOOLS Europe 2011, the International Conference on Model Transformation will take place in Zurich – Switzerland, 27 – 28 June 2011

The call for paper is out:

Overview

Modelling is a key element in reducing the complexity of software systems during their development and maintenance. Model transformations are essential for elevating models from documentation elements to first-class artifacts of the development process. Model transformation includes model-to-text transformation to generate code from models, text-to-model transformations to parse textual representations to model representations, model extraction to derive higher-level models from legacy code, and model-to-model transformations to normalize, weave, optimize, and refactor models, as well as to translate between modeling languages.

Model transformation encompasses a variety of technical spaces, including modelware, grammarware, and XML-ware, a variety of transformation representations including graphs, trees, and DAGs, and a variety of transformation paradigms including rule-based graph transformation, term rewriting, and implementations in general-purpose programming languages.

The study of model transformation includes foundations, semantics, structuring mechanisms, and properties (such as modularity, composability, and parameterization) of transformations, transformation languages, techniques and tools. An important goal of the field is the development of high-level declarative model transformation languages, providing model representations of transformations that are amenable to ’higher-order’ model transformation. To achieve impact on software engineering practice, tools and methodologies to integrate model transformation into existing development environments and processes are required. ICMT is the premier forum for the presentation of contributions that advance the state-of-the-art in the field of model transformation and aims to bring together researchers from all areas of model transformation.

Topics

Topics of interest include, but are not limited to:

Transformation paradigms and languages

• graph rewriting, tree rewriting, attribute grammars
• rule-based, declarative, imperative, functional
• textual, graphical
• pattern matching
• transformation by example
• modularity, reusability, and composition
• comparison of transformation languages
• theoretical foundations

Transformation algorithms and strategies

• model representations: graphs, dags, trees
• bidirectional transformation
• incremental transformation
• scalability
• optimization
• termination and confluence
• higher-order transformation
• evolution of transformations

Implementation and tools

• design of transformations and transformation languages
• verification, validation and testing of transformations

Applications and case studies

• refactoring
• aspect weaving
• model comparison, differencing and merging
• round-trip engineering
• co-evolution of models and meta-models
• reverse engineering (code-to-model)
• code generation by model transformation

Industrial experience reports

Empirical studies

Submission guidelines

All contributions will be subject to a rigorous selection process by the international Program Committee, with an emphasis on originality, practicality and overall quality. Papers should clearly indicate their contributions with respect to previous work. Each paper will be reviewed by at least 3 committee members. All submissions should follow the LNCS format and should include the authors’ names, affiliations and contact details. Further instructions for submitting a paper will be available at http://www.model-transformation.org/ICMT2011/.

As in previous editions of ICMT, we intend to publish proceedings in the Springer LNCS series. Moreover, a special issue with a selection of the best papers from the conference will be published in the Journal of Object Technology (JOT).

Important dates

• Abstract submission: 4 February 2011
• Paper submission: 11 February 2011
• Notification of acceptance: 14 March 2011
• Camera-ready version due: 28 March 2011
• Conference dates: 27-28 June 2011

Organization

PC chairs:

• Eelco Visser
• Jordi Cabot

Publicity chair:

• Dimitrios Kolovos

Web chair:

• Davide Di Ruscio

Steering committee:

• Jean Bézivin
• Martin Gogolla
• Jeff Gray
• Richard Paige
• Alfonso Pierantonio
• Antonio Vallecillo
• Laurence Tratt

Program Committee:

• Andy Schürr
• Antonio Cicchetti
• Bernhard Rumpe
• Daniel Varro
• Dennis Wagelaar
• Eric Van Wyk
• Gerti Kappel
• Gregor Engels
• Günter Kniesel
• Hans Vangheluwe
• Ivan Kurtev
• Janis Voigtländer
• Jendrik Johannes
• Jesus Garcia-Molina
• Jim Cordy
• Juan de Lara
• Jurgen Vinju
• Krzysztof Czarnecki
• Marco Brambilla
• Mark van den Brand
• Nate Foster
• Oscar Nierstrasz
• Paolo Atzeni
• Perdita Stevens
• Pieter Van Gorp
• Ralf Laemmel
• Reiko Heckel
• Simon Thompson
• Thomas Kuehne
• Tony Clark
• Zhenjiang Hu

Another classification of transformations

Different kinds of transformation

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

Intermediate model-to-model transformations are really an implementation detail, with no direct value to end-users—
Rafael Chaves (@abstratt) November 18, 2010

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.

About model transformations

Model Transformations are essential

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

RT @MarkDalgarno @stevekmcc interviewed by @delphinocons for the Model-Driven Software Network: http://bit.ly/bgYE9Y—
Rafael Chaves (@abstratt) November 18, 2010

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

Totally agree w/ @stevekmcc that the only model transformation that really matters is from the original model into code—
Rafael Chaves (@abstratt) November 18, 2010

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.

Paradim changes

If we look at the major trend evolutions in software engineering, we can see three big periods since the beginning:

• until 1980: procedural technology with procedural refinement as the main paradigm
• from 1980 until 2000/2010: object and component technology with object composition as the main paradigm
• since 2010: model driven engineering with model transformation as the main paradigm

This is my personal high level view on the evolution of major practices. Of course there are also other important trends, but they have not impacted as much the software production practices.

For example concurrent programming is VERY important and many efforts have been invested since the first efforts of Dijkstra in 1965 with his cooperating sequential processes. But today we are still lacking good languages to express our problems in a concurrent form. Many times we believed we were on the verge of succeeding (remember CSP, Occam, the Transputer for example).

Another paradigm that is surely important is the functional paradigm . Here again functional programming is surely VERY important but it has not yet impacted the major practices. Lisp was one of my first languages and I still remember the lectures in Lisp given by prof. Yvon Siret to our undergraduate class in Grenoble in 1967. We have teached Caml to a lot of generations of students. Today Haskell has a deep impact on many new languages that are appearing. But we do not yet see the large adhesion of programming masses to the functional paradigm and I regret it.

We could also study other paradigms like logic programming and the big hopes that were raised in the 80′s with the Japanese next generation plan. But today Prolog is not the dominant programming language in current practices.

What we can say is that the major trend of structured programming was very influential in the seventies. Top-down or bottom-up programming, procedural refinement were supported by all our great master at theat time, Dijkstra, Hoare, Wirth, Knuth, etc.  And this was the main culture until the 80′s.

Then came the object-oriented programming languages with Smalltalk, Eiffel, C++, Objective-C, Java, C#, etc.  And this changed the way we build software systems. We have been able to undertake the construction of big and huge and sometimes reliable systems with object technology that would probably difficult to build with procedural technology.

Object technology has brought a lot of advantages, including some form of reusability (not as much as we hoped, but still some form of reusability). But the main contribution of these languages is that they have shown us how to design business objects and how to mix these business objects with more technical objects or platform objects in executable programs. Today, with the help of the pattern movement, object technology is main stream and it is one of the major form of  software production with languages like Objective-C, Java or C#.

What I do believe is that with J2EE and similar solutions, object and component technology has lost its conceptual simplicity and has found its limits.

My personal conviction is that there is a big rupture arriving now in software production techniques and that this will be centered on models and model transformations.

The Village Metaphor by Antonio Vallecillo

A Journey through the Secret Life of Models

In my presentations, I quite often use the following slide stolen from Antonio Vallecillo from Màlaga.

It may be important to give here the original presentation from which this was extracted because this is much interesting reading:

http://www.lcc.uma.es/~av/Publicaciones/08/Dagstuhl-AVallecillo.pdf

This presentation was given at a Dagsthul school. The corresponding paper that you may quote may be found at:

A. Vallecillo. “A Journey through the Secret Life of Models“. Position paper at the Dagstuhl seminar on Model Engineering of Complex Systems (MECS), Aug. 2008.

Excellent reading.

Teaching Model Driven Engineering

Four lectures on MDE

I am currently working on a set of four general lectures  on Principles and Applications of  Model Driven Engineering. The content will be evolving, but the general organization is the following:

• Course #1: History and context of MDE

This first course will present the modern history of MDE (Model Driven Engineering) as a specific branch of software modeling. The differences with simulation will be first outlined. A survey of semi-formal notations will first show how the rich variety of these formalisms has been important in the history of computer science (SADT, Flow-charts, State-charts, Petri nets, Entity-association diagrams, to name only a few of them). Unfortunately the lack of unification and automation has quite often limited the utility of these formalisms but they have allowed gaining a good understanding of visual and textual semi-formal notations.  In the long history of contemplative modeling, there were probably some missed opportunities but one outcome was certainly the progressive convergence of Object Oriented Analysis and Design methods towards the consensual and normative definition and use of the UML software artifacts description language.

This UML proposal triggered in fact a lot of innovations in the area of software modeling. Many of these innovations will probably outlast the UML language itself, and are probably much more important. Since UML was not a method, another language like SPEM was necessary to describe the various software development processes. Having two languages was like having an arbitrary number of them: a need for a metalanguage (i.e. a language to define languages) became necessary. The MOF was then defined and the idea of precise characterization of languages by metamodels came then to life, even if there are still much progresses to achieve in this field. Then the evolution of software sytems, for example  when changing platforms, was described as possible transformations from languages more or les dependent on these platforms. This suggestion was made in the MDA white paper in November 2000 and became quite popular. Today MDE may be seen as a generalization of MDA.

Course #2: Theory and Basic Principles of MDE

The second course will present the basic principles of MDE from a conceptual and theoretical point of view. MDE uses typed graphs for most of the representation tasks and rule-based declarative transformations for most of the operation tasks. It relies essentially on the concepts of metamodels and model transformations.

Sometimes called Modelware, MDE is thus a graph-based and transformation based technical space. The notion of technical space will be defined and used to compare similarities and differences with other technical spaces like Grammarware.

Metamodels provide some sort of typing system on top of the models themselves. The essence of MDE is however most related to the unification of abstract models. Terminal models, metamodels and metametamodels are the most important categories of abstract models. Different operations like storage, retrieval and transformation may be applied on all abstract models.

One of the important characteristics of MDE is to represent systems by models. This relation of representation which is central to all modeling activities will be analyzed and discussed.

• Course #3: Applications of MDE

The subject of applications of MDE is vast and rapidly evolving. Usually one may consider three important areas: Generation of software artefacts,  Discovery of models from structured systems and Interoperability between heterogeneous systems. The course will show how these three areas of increasing complexity are constantly evolving.

Another classification of MDE applications considers various domains like health care, automotive, aeronautics, embedded systems, information systems, etc.

An interesting way to look at MDE applications is also through the various forms of model transormations. These transformation may be performed at system design, system maintenance or evolution and at system operation.

The course will also show how the typology of applications may be related to a classification of metamodels.

• Course #4: Migration to MDE

The last course recognizes that there are more than technical factors to characterize the move to MDE in the given context of a company or an organization: we have also to consider the organizational, social and human factors.

Starting from a list of success and failures, this lecture will analyze the process of migration to MDE from a situation where direct programming (typically in Java) is the common practice. Some indications on MDE maturity levels will be sketched. When starting an MDE project, risk factors will be analyzed. Some of these risks may be related to the maturity of the tools being employed, but others may be relaated to the human reluctance to loose some control on the direct production, maintenance or execution process.

References will be made to the migration process from procedural technology to object-oriented technology in the 80′s.  The increased difficulties in MDE come from the fact that the code is no more the reference.

These four courses may be seen as a reorganization of the content of some of the posts presented in this blog.

Where are models coming from?

On the origin of models

One important question is about the origin of models. There are several answers to this question. The most naïve one is that models comes from a UML modeler like babies comes from cabbages.

Babies come from Cabbage

The question of the origin of models is a very serious one. If we are not able to answer this question, Modelware will not fly. First we must recognize that there are two different kinds of models: original models and derived models. A model is said to be derived from another one if it has been obtained by an automatic transformation from the original one :

On the origin of models

On the origin of models

Where are models coming from?

There are three important questions about models: 

1. What is a model made of?
2. What are models useful for?
3. Where do models come from?

In this post we address the latest one: Where are models coming from?

We consider this question to be fundamental, even central to a “theory”  of MDE.

The first naïve answer is that Models are coming from Rational Rose, Papyrus or other UML Modelers. This is obviously much unsatisfactory. It is about the same level of answer as babies are born in cabbages:

Or that storks bring babies:

Let us look at a more satisfactory answer. A model may have two origins:

• either from the transformation of another model
• or from the representation of a system with the help of an observer.

1. Transformation of another model

This is the simplest way to get a model: by transformation of another model.
Mb <- t(Ma)

2. Representation of a system

This is much more difficult.