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.

Model Driven Integration

MDI

Integration (from the Latin integer, meaning whole or entire) generally means combining parts so that they work together or form a whole. In information technology, there are several common usages:

• Integration during product development is a process in which separately produced components or subsystems are combined and problems in their interactions are addressed.
• Integration is an activity by companies that specialize in bringing different manufacturers’ products together into a smoothly working system.

(from WhatIs def.)

Integrate

• Make working together, in a whole corresponding to a precise objective, elements that were not initially designed to achieve this objective.

Exemple:

• Enterprise Application Integration (EAI)
• The process of adapting a system to make applications work together when they would otherwise be incompatible.

(from Dictionary Of Database And Related Technology)

System Integration

• system integration: The progressive linking and testing of system components to merge their functional and technical characteristics into a comprehensive, interoperable system.
• Note: Integration of data systems allows data existing on disparate systems to be shared or accessed across functional or system boundaries.

Data Integration

A broad spectrum of data is available on the Web in distinct heterogeneous sources, stored under different formats. As the number of systems that utilize this data grows, the importance of data conversion mechanisms increases greatly… A key observation is that, often, the application programs used by organizations can only handle data of a specific format… To enable a specific tool to manipulate data coming from various sources, a translation phase must take place…The naive way to translate data from one format to another is writing a specific program for each translation task… A sound solution for a data integration task requires a clean abstraction of the different formats in which data are stored, and means for specifying the correspondences between data in different worlds and for translating data from one world to another.

Serge Abiteboul & al.

Tools for data translation and integration

Data engineering Vol. 22,N.1, march 1999.

Interoperability (def.)

The goal of Integration

The goal of integrating two systems Sa and Sb is not always to replace these two systems by an equivalent ssytem Sc. Very often it is to keep these ssytems as is, but to add another communication system between them.

Two steps solution to integration: MDI

Interoperability and Integration are issues covered by computer science since the beginning. The main question is what is MDE bringing to the field.

The idea is that with models we are able to apply a two-step integration process. In the first step, heterogeneous systems are represented by homogeneous models (possibly conforming to different metamodels). In the second step, these models may be interoperated by model transformations.

Language (Metamodel) Driven Integration

The general method to solve interoperability problems between two heterogeneous systems Sa and Sb is thus becoming quite clear. Instead of considering each such problem as an ad hoc problem, we may follow a general method. For each system, we consider a metamodel capturing the nature of the heterogeneity we want to resolve. Assimilating each system to a model conforming to a specific metamodel allows us to solve a first level of interoperability (probably the most difficult). Then the remaining alignment between the two models is solved by classical exogeneous model transformaions (i.e. transformations between models conforming to different metamodels). This two step process may be applied to virtually any heterogeneous ssytem integration problem.

General Model Driven Integration method

If this two-steps  method for solving integration problems is becoming clearer, a lot of difficulties lie ahead. How to define the metamodels, how to define the two categories of transformations, etc.

In particular, the system to model and the model to system transformations are much more difficult to define than the model to model transformations. The reason is that they essentially depend on the nature of the systems and of their deep characteristics. We must perform an analysis of the real nature of the systems and, according to the result, use different sets of solutions. For example, the systems to be integrated may be:

• Source Code
• XML
• Data Bases
• Raw data
• Business sytems
• Platform
• Tool
• Enterprise
• Requirements
• Static systems
• Dynamic systems
• etc.

Let us take for example the first situation which is quite typical in the case of software modernization. We know that in this situation the source code conforms to a given grammar. Thus, with these kinds of systems, we have to align a grammar and a metamodel. Seems simple, but only this simple step is quite complex. In the Eclipse system, solutions like XText or TCS have been defined to achieve this particular goal. In simple situations of model to system transformations, we could even use proprietary or standard so-called model to text transformations.

As we see, each situation has to be independently analysed and, if possible, generic tools should be used. In the previously defined problem, we have assumed that the grammar describing the source code is readily available. But even this simple hypothesis is not always verified. Sometimes one would have to build the precise grammar before starting to align the grammar and the metamodel.

What is MDE?

Model Driven Engineering

There seems to be some consensus about the qualities of MDE, but what is exactly MDE? I will try to address this question in this post. First we need to consider separately the base technology and the application scope.

1. The base technology of MDE

The main idea is to consider a level of uniform representation where all artifacts are models, composed of model elements. A model is a typed graph which elements (edges and nodes) are typed by the nodes of another graph called its reference graph (we say that it conforms to the reference model). At the bottom of the hierarchy we have terminal models that represent a given system. A terminal model conform to a metamodel. Usually we have a three-level hierarchy made of terminal models, metamodels and a metametamodel. The relation of conformance andrepresentation are the two key relations in MDE: 

Most modeling frameworks use a three-level hierarchy of metalevels. They differ mainly on the metametamodel used (MOF, ECore, KM3, etc.).

MDE draw its strenght from the unification principle. This means that most artefacts may be considered as abstract models. This is illustrated below.

2. The application scope of MDE

Initially MDE had a limited scope, mainly in the area of software development. People used to talk (and still talk) about MDD (Model Driven Development) to qualify this kind of application where executable code is generated from one or more abstract models. When these metamodels conform to OMG specified metamodels, we talk about MDA(tm) for Model Driven Architecture. Of course, one of the main metamodel supported by OMG is UML.

MDD has been and is still quite successful and many success stories have demonstrated an excellent ROI. But at the same time several new possible applications of the base MDE technology have been discovered and now MDD is only one particular branch of MDE.The first new MDE application area is MDRE (Model Driven Reverse Engineering). Contrary to MDD where code is produced from models, in MDRE models are produced from code. To emphasis this difference, the OMG calls this approach ADM (Architecture Driven Modernization), the reverse of MDA. The techniques for extracting models from legacy code (backward engineering) are different from the techniques for producing code from models (forward engineering), but both heavily use model transformation. 

The similarity between MDD and MDRE is that both approaches rely on models of code. There is now an important trend that considers that MDE base technology can be even more broadly applicable to models of the data.

In the previous figure there are three kinds of MDE approaches:

• MDSD (Model Driven Software Development) for generating code from models. Transformations are here executed at <b>development<b> time.
• MDRE (Model Driven Reverse Engineering) for generating models from code. Transformations are here frequently executed at <b>maintenance<b> time. The typical application here is software modernization.
• RTM (Run Time Modeling) for executing model transformation at run time, not at development or maintenance time. The typical application here is to achieve <b>interoperability between heterogeneous systems<b>.

When we look at OMG standard, MDA corresponds to MDSD and ADM corresponds to MDRE. There is still no precise OMG standard for RTM. Note that RTM is mainly coping with models of data and not models of code and this is a big difference with MDSD and MDRE. RTM is often used in MDI (Model Driven Interoperability).