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.

Bits of History (Relations between Model and Metamodel)

Bits of History (Abstract Models)

An interesting tradition at every OMG meeting is the ORSMC meeting. It used to take place on the Sunday before the technical meeting week, but recently the meeting day became more flexible. The main goal of this meeting is to edit the “MDA Foundation Model” under the control of the AB (Architecture Board). The latest edition is ormsc/10-09-06, version of september 2010.

Although the “MDA Foundation Model” is an internal OMG document, it gives very useful information on how the modeling architecture is organized. One typical figure represents the main involved entities and their relations:

Some choices are probably debatable, but this shows the overall organization of modeling artifacts. If we look at this fragment, we can paraphrase the diagram as follows:

1. A model is composed of model elements (zero or more).
2. A metamodel is composed of metaelements (zero or more)
3. A model is written in the language defined by its metamodel(s) (relation ModelConformsToMetamodel);
4. A metamodel is a model (Metamodel inherits from Model).

The last property is quite important because it states that operations applicable to models (e.g., store, retrieve, transform, etc.) may also be applied to metamodels. This is the basis of model unification.

 

 

 

 

 

Perhaps I would have preferred something like the following, but this is not central.

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.

MDE for Managing Complex Systems

Towards an MDE implementation of the Macroscope

The ModelPlex European IP is now finished.  The target of the project was  the application of MDE to complex systems. The basic use cases were provided by Thales, Telefonica, WesternGeco ( Schlumberger) and SAP.

Among the lessons of  this project, we have learnt that MDE is a good technology to manage complex systems, maybe the only possible technology.

Some basic facts

Real problems are no more isolated.

They are global and usually very  complex.

Complex systems are difficult to manage.

Traditional technologies (like procedural, 00, XML, …) do not work well on global problems.

MDE may be able to help here.

The only possible weapons against  complexity are conceptual simplicity  and unification.

“Everything is a model” may be used as a guiding principle.

The basic charasteristics of Computer-Based Complex Systems (CBCS) may be outlined:

• CBCS: Computer-Based Complex System
• A complex system with a significant number of hardware/software components
• Compare with de Rosnay’s biological or ecological complex systems
• A CBCS is composed of a large number of components
• A CBCS is constantly in evolution
• Past, present, future
• No stops when parts are added, removed or under maintenance
• A CBCS has a structure (static architecture) and a dynamic behavior
• A CBCS is composed of components that may be also CBCSs (no limit in nesting)
• A CBCS has a goal defining its purpose in the context in which it is operating
• The goal of a CBCS is part of its metadata
• A CBCS has a heterogeneous-based engineering
• A CBCS is a distributed system
• A CBCS may not be understood by one unique human operator
• The interactions between different parts of a CBCS follow specific patterns and may be characterized by the relations that hold between them
• These relations may be implicitly or explicitly defined

Managing CBCS with the Macroscope

The objective is to implement the functionalities of the Macroscope proposed by Joel de Rosnay in practice, for example as a set of Eclipse Modeling tools.

The “Macroscope” is a  book on the systems approach

Dr. Joël de Rosnay, a molecular biologist, systems theorist, science writer, and futurologist, is presently Director of Strategy of the Cite des Sciences et de l’Industrie at La Villette (near Paris). He is an associate of the Principia Cybernetica Project.

Principia Cybernetica Web now offers the complete text and drawings of the book “The Macroscope” by Joël de Rosnay. It was originally published in 1979 by Harper & Row, (New York), but is now out of print. Therefore, they have made it available on the web at http://pespmc1.vub.ac.be/macrbook.html.

This book is an excellent, easy to read introduction to cybernetics and systems thinking, with applications to living organisms, the economy and the world as a whole. The main theme is that the complex systems which govern our life should be looked at as a whole, rather than be taken apart into their constituents. The different systems, processes and mechanisms are beautifully illustrated with examples and pictures. Although the text is over 20 years old, this visionary document is still highly relevant to our present situation and state of knowledge. It is particularly recommended to people who wish to get an understanding of the basic concepts and applications of systems theory and cybernetics.

I have read this book several times and each time I learn something new. The book is about living organisms, biology or economics, but many lessons and ideas could also be made relevant to software based complex systems.

 

 

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.

The Eclipse Modeling Platform Project

The Modeling Platform Project.

The Modeling Platform is a vision to create an integrated modeling development platform and toolchain based on Eclipse technology. A number of companies are participating in developing a list of requirements and vision for the Modeling Platform. The following wiki collects the presentations and documents created by the participants:

http://wiki.eclipse.org/ModelingPlatform

There is a quite interesting report on the potential Usage of Eclipse Modeling Platform at UBS:

http://wiki.eclipse.org/images/9/9c/EMP_Usage_UBS.pdf

The Zeligsoft report summarizes the situation of fragmentation in Eclipse Modeling and motivates the need for the Modeling Platform Project:

http://wiki.eclipse.org/images/d/dc/Report.external.bvs.pdf

The “Twenty modeling things” presentation at EclipseCon 2010 is also completely related to EMP:

http://www.eclipsecon.org/2010/sessions/?page=sessions&id=1315

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 Principle of substitutability

SUBSTITUTABILITY

Substitutability is a principle in object-oriented programming. It states that, if S is a subtype of T, then objects of type T in a computer program may be replaced with objects of type S (i.e., objects of type S may be substituted for objects of type T), without altering any of the desirable properties of that program (correctness, task performed, etc.)

In Modelware the principle of substitutability also exists, but with a different definition. It states that, if M is a fidel (faithful) representation of system S, then M can replace S to answer some categories of questions about S.

The principle of substitutability in model driven engineering has to be credited to Minsky:

substitutability according to Minsky

Definitions

A set of definitions for MDE

The core organization of MDE can be captured by a simple set of definitions:

Definition 1. A directed multigraph G = (N_G, E_G, G_G) consists of a set of distinct nodes N_G, a set of edges E_G and a mapping function Γ_G :  E_G → N_G x N_G

Definition 2. A model M = (G, ω, m) is a triple where:

• G = (N_G, E_G, Γ_G) is a directed multigraph
• ω is itself a model, called the reference model of M, associated to a graph G_ω = (N_ω, E_ω, G_ω)
• μ : N_G ∪ E_G → N_ω is a function associating elements (nodes and edges) of G to nodes of G_ω (metaElements)

In most technologies,  a three level engineering organization has been choosen (see technical spaces).

In MDE, the following is usually assumed:

Definition 3. A metametamodel is a model that is its own reference model  (i.e. it conforms to itself).

Definition 4. A metamodel is a model such that its reference model is a metametamodel.

Definition 5. A terminal model is a model such that its reference model is a metamodel.

The three last definitions may be drawn as follows:

The conformance relation between models

The objective now is to define the possible usages of a model. Consequently, in all the following, model will mean “terminal model”.

Definition 6. A system S is a delimited part of the world considered as a set of elements in interaction.

Definition 7. A model M is a representation of a given system S, satisfying the substitutability principle (see below).

Definition 8. (Principle of substitutability). A model M is said to be a representation of a system S for a given set of questions Q if, for each question of this set Q, the model M will provide exactly the same answer that the system S would have provided in answering the same question.