Endangered (technical) species

I am amazed by the rapid disappearance of many references to important technical contributions. It is normal life that new proposals appear and that old proposals disappear. But I find annoying that direct Web references vanishes so quickly. It is sad because some of these proposals were not bad or low quality, they just did not meet their public at the time for reasons that were often more political than technical. It is a problem because so many people now believe that something that is not on the Web does not exist and has never existed.

I started doing some research on pre-MOF metamodeling techniques and my first idea was to look at a very interesting Web site that was built a long time ago by my friend Johannes Ernst. This site was simply  ”www.metamodel.com“. But unfortunately this site appears to have completely disappeared and the Web pointer now redirects to Adaptive, the company of another good friend Pete Rivett.

Fortunately some people have saved small parts of this initial site, for example I managed to find track of the discussion What is metamodeling, and what is it good for? on another site: infogrid.org.

This made me realize that we lost most memories of an important metamodeling initiative called CDIF. This was a real achievement in metamodeling. Paraphrasing Tony Hoare, we can say that CDIF was an improvement on most of its successors, including the multiple variants of MOF and also ECORE. It is a pity that the memory of CDIF is disappearing so quickly because there are many lessons that we can still draw today from this interesting proposal.

Fortunately we can still find some interesting archives like the paper by Oscar Nierstrasz and his colleagues on the use of CDIF for reengineering Tools. This paper was published in 1998. Is that so old that we should completely forget about this technology?

I am convinced that MOF and UML have not done so well as to justify that we should delete all references to previous modeling proposals. On the contrary I believe that we can still find a lot of inspiration in older technologies. As we say in french, “C‘est dans les vieux pots que l’on fait la meilleure soupe” (experience always wins the day).

Does someone have a list of pointers on CDIF or better has saved some part of this very valuable technology heritage?

My main reference is still the paper by Rony Flatscher:  ”An Overview of the Architecture of EIA’s CASE Data Interchange Format (CDIF)“. I know that Rony also published a book on CDIF, but I understand it was in German and was not translated in English.

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.

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.

First Generation Metamodels

I tried to find some first generation “metamodels”. It is quite instructive to question how they were actually used.

Let’s call it Flowchart #1. Here is another one:

This is Flowchart #2.

Here we have three ones, from left to right: Flowchart #3, Flowchart #4, Flowchart #5.

Now, in the following picture, we have a metamodel Flowchart #6 (on the left) and a terminal model Model #1 (on the right):

Finally another terminal model Model #2 :

One question: to what metamodel does Model M#2 conforms?

One can see from all these simple examples that Flowcharts are some kind of rudimentary ontology i.e. a shared and conceptual set of abstraction for computation.

The next generation could be illustrated by the OMT or the Booch notations. The following figure shows the visual concrete syntax associated with Booch diagrams as well as three sample terminal models.

One remark that can be done here is that each element from a terminal model (diagram) relates to a corresponding symbol in the concrete syntax of the metamodel. This relation is called μ here.

Models and Models

Sorry, the word model is semantically overloaded. This is why a Google search on “Models EveryWhere” may bring different types of result. Here are some samples:

Wrong: http://snapsanddaps.blogspot.com/2009/05/models-models-everywhere.html

Good: http://www.iceis.org/iceis2007/Hall_Of_Fame/jbezivin/jbezivin_2001.pdf

Wrong: http://themoment.blogs.nytimes.com/2008/02/06/for-the-moment-models-models-everywhere/

Good: http://tcagley.wordpress.com/2009/05/18/models-models-everywhere/

Wrong: http://diggingpitt.blogspot.com/2007/01/models-models-everywhere.html

Good: http://efoundations.typepad.com/efoundations/2006/11/models_models_e.html

Wrong: http://www.pbase.com/tracktime/image/113742714 (train models)

Good: http://portal.acm.org/citation.cfm?id=884683

Wrong: http://www.travelblog.org/Photos/2013915.html (food models)

Beware: These are plastic food models. If you steal them, don’t eat them

By the way, this picture shows an interesting example of a “tagged model“. The idea of decorating a model with additional information is quite interesting. Here we see that a “price tag” has been added to each model element. It would be much less elegant to add this tag  to the real dishes when they are brought to the customer at the restaurant table. Any other metadata could easily be associated to such model element like provenance, description, etc.

At least this set of samples may help one to start a learning process for disambiguisation of different meanings of the word “model”

U-Languages or M-Languages?

I cannot resist quoting Stefan Tilkov’s blog : http://www.innoq.com/blog/st/

——————————
” … Once upon a time, I used to believe the OMG shared the vision of modeling based on custom metamodels — after all, what MS now claims as its innovation is something that is very much aligned with the original MOF concept. Sadly, though, with OMG’s ridiculous monster of a modeling language that aims to be everything to everybody, this seems to be no longer the case. (If anybody needs proof that Tim Bray is right in asserting that standards bodies should never invent anything, and is tired of using another well-known monster to do so, UML 2 would be a great candidate.)

So in the end, it seems to come down to MOF in its sort-of-working semi-compatible non-standardized incarnation (EMF), embedded into Eclipse, vs. Microsoft’s proprietary DSL stuff, embedded into Visual Studio. And the strangest thing is: I’d rather place a bet on something that is backed by eclipse.org than on an OMG standard nobody gives a fuck about. Care for another example? Take this.”
——————————

So seems that the old debate on (Unique/Unified/Universal) languages or U-languages is starting again. After the failure of languages like PL/1 and ADA to name only two of them, it seems that what happened on the programming scene is on the verge of happening again on the modeling scene with UML 2.0. [By the way it is funny to notice how old ADA unconditional supporters are easily tempted to back UML 2.0. ]

The OMG camp has always been divided between the tenants of U-languages (UML) and the tenants of M-languages (Meta-Languages, e.g. MOF based). Until now, at the cost of constant compromises and aligments, these views have been cohabiting in the MDA approach.

But today, with the emergence of the very strong DSL trend in industry and research and the clear commitment of Microsoft “Software Factories” into the M-language camp, the cursor seems to move away from the UML 2.0 users and profilers.

This does not come as a surprise since it is only an aligment on what is already happening in the XML technical space. After all, the co-existence of the various XML schemas and DTDs is not apparently such a catastrophic move, at least from the point of view of the users.

Departing from the apparent comfort of huge, unprecise and difficult to specialize monolithic languages like UML 2.0, lead us to the apparent creative and productive environment of multiple coordinated languages. It is quite easy to see what could be achieved with the help of small, well focused and precise DSLs. However we have still many problems beyond of us to solve. The big challenge is how to cope with the fragmentation problem, i.e. the co-existence of hundreds or even thousands of these DSLs. For the time being we have only two ways of coping with this: the existence of a well founded M3-level metalanguage (i.e. the MOF) and the possible forthcoming QVT standard for model transformation language, in the case that this effort finally produces a satisfactory and realistic proposal in 2005 (still to be proved). However, even with a very precise metametamodel and a very well designed model transformation language, we we still have a long way to go before demonstrating the practicality of the approach.