Metamodel Transformation in Model Driven Engineering

Departement Informatique
Telecom Bretagne

Author
GOLRA Fahad Rafique

Supervisors
DAGNAT Fabien
BEUGNARD Antoine

Internal Technical Report No. 20102-04A

4 octobre 2010
 Metamodel Transformations in Model Driven
Engineering
Fahad Rafique Golra

4 octobre 2010

It is long since modeling is being used to study the behavior of complex

systems. But modeling has emerged out to be a key step for systems de-
velopment in the recent era. In order to unify all the modeling endeavors
regarding software engineering, a lot of research has been done. Modeling
has gone up to multiple abstraction levels, so as to add precision to the mo-
deling process so that the models can better describe and specify the system
under study, as ”model is not the reality” [12].

1 Modeling Layers
When talking about the modeling layers, there are different poles ha-
ving different interpretations of their own. But they all take modeling as
a multi-layered phenomenon. Talking about two adjacent layers, one layer
would be M n−1 and the other would be M n , which allows us to think of an
unlimited number of layers upon which the system modeling can be based.
The other most common approach is the four-layers metamodeling pyramid
of Object Management Group(OMG) [3], presented in Figure 1. Here the
first layers is M 0 , the data layer where the final running system lies. Above
this layer is M 1 , the Models layer where lie all the models related to the
specific system under study. Then above this layer lies M 2 , the metamodel
layer. The metamodel layers is the concrete layer to which all the models
of M 1 conform. A very good example of this layer can be the metamodel
of Unified Modeling Language (UML) itself i.e. UML describes itself at this
layer. And finally in M 3 lies the Meta Object Facility (MOF), which can
be termed as meta-metamodel. All the metamodels further conform to this
MOF. Thus UML metamodels conform to the MOF, residing at a higher
layer of abstraction. MOF is the topmost layer and it is built upon itself.

We have reproduced the OMG-four layer hierarchy from Henderson-

Sellers and Unhelkar [8] in Figure 2. Atkinson advocates that this hierarchy
uses strict metamodeling where each layer has an ”instance-of ” relationship

1
Figure 1 – The four-layer metamodeling pyramid from MOF Specifications
after [2]

to its upper layer [5, 6]. An instance-of relationship is a representation from

object oriented paradigm, where an object is said to be an instance of a
class. In this case the object being an instance of a class holds a state. We
on the other hand, do not agree to the fact that instance-of relationship is
the only relationship between these layers ; a more precise description would
be to have either instance-of, conforms-to or representation-of relationships.
The ”conforms-to” relationship can be described as meeting a standard. So
in such a case we can say that models conforms-to metamodels aka models
take metamodels as a standard and meet their specifications. So the diffe-
rence between the instance-of relationship and the conforms-to relationship
can be stated by the fact that instantiation gives the notion of develop-
ment using templates 1 whereas conformance gives a notion of development
in accordance with some standard. The third relationship ”representation-
of ” defines a relationship between two models such that they both conform
to a single metamodel and the later is a representation of the former.

The representation of relationship is defined using the concepts of ”In-

tentions” in [16], where they argue that it is not compulsory for a model
to share an intention with the model it represents. Both the models (one
being represented and the one representing) can share partial or complete
intentions also. They further classify the nature of representations as ana-
lytical and synthetical representations. Analytical representation is the one
where the source model (X) can be derived or abstracted from the target
1. templates not as in programming languages like C

2
 Figure 2 – OMG four-layer hierarchy after [8]

model(Y ) (shown in Eq.1).

X−
→ Y : ∃Tα | X = Tα (Y ) (1)
α

Where as in a synthetical representation, the target model is generated

from the source model (shown in Eq.2). They argue that both these types
of representations are transformations in Model Driven Engineering.

X−
→ Y : ∃Tγ | Y = Tγ (X) (2)
γ

Till date there is no definition of metamodel upon which all the stake-
holders unanimously agree. According to UML2.0 MOF Model specification,
”A metamodel is a model used to model modeling itself” [3], where as many
contradict the idea of terming a metamodel as a model of models [13]. A me-
tamodel is also defined as a ”specification model for a class of SUS (System
Under Study) where each SUS in the class is itself a valid model expres-
sed in a certain modeling language” [4]. Amongst all the different points of
view regarding the metamodels, one common thing can be sensed that there
exists a relationship ”conforms-to” between the models and their metamo-
dels. This is the reason why, we disagree to Figure 2 and agree to Figure 3.
As already discussed we are using an unlimited number of modeling layers,
in order to have the flexibility of expression. In practice much of the layers
are not used, but taking off the restriction gives us the authority to model
with clarity. Other technical spaces are mostly using three levels.

– Extensible Markup Language (XML) : documents, schemas and

the schemas of XML Schema for XML.
– Extended BackusNaur Form (EBNF) : programs, grammars and
the grammar of EBNF.

3
 Figure 3 – Conformance relationship between modeling layers

In Figure 3 we see that either instance-of, representation-of or conforms-

to relationships can be used. In fact when talking about the four layer hierar-
chy, the relationship between M 0 layer and M 1 layer is purely instantiation
where objects reside at the data layer. But for the higher abstraction layers,
the models conform to the metamodels and then the metamodels further
conform to the meta-metamodels or Meta Object Facility. And then for hi-
gher abstraction levels, there are situations where instance of relationship is
used. We are going to discuss it later.

2 Model Transformation
There are different technologies used to model the system out of which
Model Driven Architecture (MDA) has been proposed by OMG in its UML2.0
specification [1]. MDA is in fact a representation of the system design in
terms of models that can be transformed from one form to another till the
generation of code and is based on a certain set of rules. An overview of
MDA can be found in [9].
As shown in the Figure 4, a transformation complies to its transforma-
tion definition, which contains all the transformation rules. A transforma-
tion rule is an equation which maps the constructs of source language to the
constructs of target languages. A rule is defined using different variables,
patterns and logic [9]. The model transformation is defined in [4], as :

A transformation is the automatic generation of a target

model from a source model, according to a transformation de-
finition. A transformation definition is a set of transforma-
tion rules that together describe how a model in the source lan-
guage can be transformed into a model in the target language.

4
 A transformation rule is a description of how one or more
constructs in the source language can be transformed into one
or more constructs in the target language.
We do not agree with this definition of transformation, as it accounts only
for the automatic generation transformations. In our point of view, a trans-
formation can either be automatic or it can be semiautomatic. An automatic
transformation would be a transformation where no manual intervention is
required. But looking from an abstract point of view, a composite transfor-
mation(explained in the next section) may be composed of automatic trans-
formations and some manual interventions. Thus we stick to the fact that
a transformation can either be automatic or semi-automatic. Furthermore,
this definition does not take into account the fact that a transformation can
have multiple models as inputs and outputs. We also contradict with the
idea that the model changes from source language to target language, as at
times, like in optimization, the source and the target languages can be the
same.

2.1 Composite Transformation

The key feature in the Model Driven Architecture is the model trans-
formation, where model M1 is transformed to M2 and so on until Mn . The
complete transformation here from M0 to Mn can be termed as a composite
transformation which comprises of different unit transformations e.g. M0 to
M1 . Now this unit transformation takes one (or more) source model(s) and
transforms it to one (or more) target model(s). The term model out here
encompasses all sorts of models that may vary from abstract analysis, to
concrete design models and further till source code [15]. The source code
is also termed as a model because it models the SUS. The transformation
from source to target models can either be automatic or partially auto-
matic depending upon the source and target models. As a matter of fact
there are two types of transformations : M2M transformations that have
models as inputs and outputs and M2T transformations where input is a
model but the output is a text, document, analysis or code. Talking about
M2M transformations, each transformed model in the process conforms to
a certain metamodel, that lies in an upper abstraction layer of these models.

Now the point here is that the models are transformed in the M n−1 layer
and their respective metamodels remain at M n layer, but the metamodels at
times remain the same. Figure 5 can be referred to see this transformation.
The transformed model Mι supposing that its not the first model created is
transformed to Mι+1 , where Mι conforms to some metamodel M Mι where
as the Mι+1 conforms to some other metamodel M Mι+1 . So in this case,
all the transformations are being done in the M n−1 layer (which if in the 4

5
 Figure 4 – Transformation insight

Figure 5 – Model Transformation in n-layer hierarchy

layer architecture would have been the model layer).

2.2 Unit Transformation

We have already defined a unit transformation as a transformation that
takes one (or more) source model(s) and transforms it to one (or more)
target model(s). Now what makes it different from the composite transfor-
mation is that it can not be taken up as a collection of transformations. Each
unit transformation has got its own transformation definition, which may
comprise of multiple rules. But these multiple rules should not be confu-
sed with multiple transformations, as they are the building blocks of a unit
transformation.

6
 Let M0 , Mn be the models that conform to the metamodels M M0 and
M Mn respectively. Then a transformation can be viewed as

TD
M M0 −→ M Mn M n Layer

↑ ↑

M0 −→ Mn M n−1 Layer
T

where T D : M M0 → M Mn is the transformation definition which oc-

curs at the M n layer, and T = M0 → Mn is the transformation application,
which occurs at the M n−1 layer.

If M0 is the initial model and Mn is the goal model. Thus the composite
transformation 2 Tw transforming M0 to Mn (M0 → Mn ) is


Tw = Tj J∈[0,n]

Then the unit transformation can be described by I which is a subset of

J (J being the sequence of transformations), such that it can have only one
transformation, which can not be further decomposed into multiple trans-
formations. So this unit transformation (Tι ) can be described as

| M Mι −→ M Mι+1 |
| ↑ ↑ |
| Mι −→ Mι+1 | ι∈I
Tι
2. Composite transformations are denoted using double headed arrow

7
2.3 Transformation Process
As we discussed earlier that modeling is no more an assistance to un-
derstand the system under study, it has become a part of the development
process. Now models can be transformed from the requirements gathering
process till the code generation and even testing using model transforma-
tions. So we take a transformation as a process, and we would define a
transformation process as :

Definition 1. It is a process in software development, either automatic or

semi-automatic which takes one (or more) models of a kind and transforms
it into some other kind of model(s). A kind of model is differentiated through
its characteristics, for example it can be composed, decomposed, refined, abs-
tract, optimized etc.

For a transformation we have to have one (or more) source model(s).

These models can then be transformed into the target model(s), undergoing
a unit transformation or a series of unit transformations.

3 Modeling Model Transformations

As we stated earlier regarding the Model Driven Architecture, its key
feature is model transformation. Considering the four-layer metamodeling
hierarchy, these transformations occur at the M 1 layer. As all the models
for a system reside in that layer, the transformation gets the target and the
source model from the same layer. And then all the metamodels to which
these models conform reside in the M 2 layer. But taking the general n layer
hierarchy of modeling, we state that the transformation occurs at M n−1
layer. And all the source and target models that are either used or genera-
ted by the transformation conform to some metamodels that reside in the
M n layer. Having the flexibility of using a general n layer modeling hierar-
chy, we can explain the transformation in a much better way. Now instead of
saying that the source or target models reside in some specific layer, we say
that these models can reside on multiple layers. Now comes in the fact that
a transformation can either be vertical or horizontal. Horizontal transforma-
tions are defined as the transformation where source and target models lie at
the same abstraction level whereas in vertical transformation they lie at dif-
ferent abstraction levels [15]. Examples of horizontal transformation can be
re-factoring and migration, whereas an example of vertical transformation
can be refinement. So we can say that horizontal transformations reside in
the same layer, whereas vertical transformations span over multiple layers.
Now for the purpose of generality we can say that metamodels reside at a
M n layer and the models along with their transformations reside at M n−ι

8
 Figure 6 – Intention modeling of vertical transformation

layer, where ι = 1, 2, . . . depending upon the kind of transformation.

Using the intentional modeling defined in [16], we have modeled the dif-
ference between horizontal and vertical transformations. Taking abstraction
as a subset of the intention in the context of model transformations, we
denote it by S. M1 being the source model and M2 being the target model
in this intentional modeling, both have a representation of relationship bet-
ween them. Figure 6 is presenting the vertical transformation, where M2 is
a refinement of M1 . As the (subset of) intention S depicts that it has exten-
ded the intention for the transformation. Here, we have M1 as a synthetical
partial representation of M2 , depicting the fact that M2 is generated from
M1 . Then we have a synthetical partial representation of M1 as S, which
depicts that the intention of abstraction extends the initial level of abs-
traction of M1 . And finally we have an analytical complete representation of
M2 as S, which states that M2 and S have same intention generated from S.

We can see that in Figure 7, the representation of relationship bet-

ween M2 and M1 remains that same. This synthetical partial representa-
tion amongst the two depicts that this is also a transformation. But as this
is a horizontal transformation, where for example this transformation can
be a refactoring, and the level of abstraction remains the same in source
and target models. Here M2 has an analytical extended representation to
S, depicting that, M2 has been generated from S, and its intention covers
the intention of S. The complete synthetical representation of relationship
between M1 and S depicts that the intention of S has been generated by
M1 , and remains the same as that of M1 .

When following the model driven engineering, in the process of these

transformations, a Platform Independent Model (PIM) is transformed to a
Platform Specific Model (PSM), which is then finally transformed into the
final code for some specific platform. PIM is defined using an appropriate
Domain Specific Language (DSL). Then using a Platform Definition Model

9
 Figure 7 – Intention modeling of horizontal transformation

(PDM) this PIM is transformed to a PSM. PSM’s in turn are free to use
DSL’s or general purpose languages. But this transformation from PIM to
PSM is not always a one step process, and each step produces a unique
transformed model. Each transformed model conforms to a metamodel. But
taking into account the horizontal transformations one (or more) source mo-
del(s) can be transformed to one (or more) target model(s), where both of
them lie in the same layer. Now considering both the transformations we
can say that it follows a two dimensional progression as in Figure 8

As it can be seen from the Figure 8, models of a specific systems are

not just lying in a single abstraction layer. In this example the complete
transformation spans across four layers, whereas, more levels of abstraction
can be further added for a more clear picture. As this figure explains the fact
that models can reside on multiple layers, same way metamodels can also
reside on multiple abstraction levels. Meta model extensions can reside in
the layer following metamodels, thus a complete metamodel spanning over
multiple abstraction levels.

One can notice in Figure 8 that the vertical transformations span over
two adjacent layers, and the horizontal transformations remain within a
layer. This must not be confused with the fact that the source and the tar-
get models for horizontal transforms conform to the same metamodel. As a
matter of fact, this difference is explained well in [17], where the transfor-
mations between the models of the same modeling language are termed as
rephrasing and the transformations amongst models of different modeling
languages are called translation. A more clear taxonomy is provided in [15]
where the term endogenous transformations is used for the transformations
where the source and the target models conform to a single metamodel, whe-
reas exogenous transformations are defined as transformations where source
and target models conform to different metamodels. So in the transforma-
tions shown in the Figure 8 both the horizontal and the vertical transfor-

10
 Figure 8 – Model Transformations spanning over multiple layers

mations can either be exogenous or endogenous. Besides this we can also

notice that the transformation M2C where the source and target models are
the same is an example of transformation called an in-place transformation
while the rest of the transformations are out-place.

As we discussed earlier in this article, in a general n layer modeling

hierarchy, the relationship between the models in two adjacent layers can
either be instance-of, conforms-to or the representation-of . In Figure 9, the
relationship between M1 and the PIM is the representation-of relationship,
whereas the same M1 conforms-to the same metamodel of PIM i.e. M M1 .
The model M2 and M3 both have a conforms-to relationship to M M2 . And
PSM has an instance-of relationship with M3 and a conforms-to relation-
ship with M M3 . Out here we have seen that models are having conform-to
relationships to the metamodels lying not just on the upper abstraction level
but to a much more abstract level. For example the M1 residing at M n−2
layer conforms-to M M1 residing at M n layer or the PSM residing at M n−3
layer conforms-to M M3 residing at M n layer. These kinds of relationships
are an open research fields and can be handled by deep instantiation based
metamodeling [7] or powertype-based metamodeling [10, 11].

11
 Figure 9 – Relations between modeling layers

4 The Meta-Transformation Definition

The study of constraints in detail would help us elaborate the process in
detail. As for example a constraint stating that the transformation T1 can
only be applied to some Model M10 if either of the two hold

1. M10 = M1
2. M10 ' M1

In the case (2), the ( ' ) symbol means that both models conform-to
(µ) a single metamodel. This definition of conforms to can be stated as,

M ' M 0 ⇐⇒ ∃M M | (M µ M M ) ∧ (M 0 µ M M ) (3)

Now the novel idea being proposed is that model transformation no

doubt can be done at the M n−1 layer but if a metamodel transformation
can be carried out at the M n layer, that would allow the automatic or semi-
automatic creation of metamodels. Thus it would create a recursive process
where models at M n−1 layer would conform themselves to metamodels at

12
 Figure 10 – A meta transformation definition

M n , and would undergo a transformation. Same way, the metamodels at the

M n layer would conform themselves to meta-metamodels at M n+1 layer,
and they would also undergo a meta transformation. Just the way transfor-
mations comply to the transformation definitions, the meta-transformations
would comply to the meta-transformation definitions. The mapping between
the transformation definition and the meta-transformation definition would
finally help the system stability, reliability and correctness.

This can be viewed in Figure 10 that the transformations are taking

place at M n−1 layer, their transformation definitions residing in M n layer
and then the Meta Transformation Definition residing in the M n+1 . The
relationship between transformations and transformation definitions is the
instance of relationship, but the transformation definitions are mapping to
the meta transformation Definition. Further more, we can also see that mul-
tiple transformation definitions are mapping to a single meta transformation
definition, here the phenomenon is the same as of composite transforma-
tions. The Meta transformation definition defines the universal constraints
for transformations, that the transformation definitions follow.

13
 At the end, what we would want is an automatic generation of not only
the models but also the metamodels to which the methodology models map.
Thus rules would be needed to allow metamodel transformation that can im-
plement this novel idea. Such a collection of rules would be in fact a language
for metamodel transformation definition. This idea should not be confused
with Higher Order Transformations[14], as the higher-order transformations
take transformations as input and then produce a transformation as output.
This is true that they also handle transformation at a higher level of abstrac-
tion but they work on transformations instead of metamodels. In our work,
the source and target models are not transformations but the metamodels,
where we plan to add up business constraints and fine transformation defi-
nitions in transformation model and then add up some universal constraints
to the meta-transformation definition.

Furthermore having meta-transformation definition in practice, we can

then apply it to any specific specialization of software engineering such as
component based software engineering.

Note : This document is undergoing preparation under the supervision

of Fabien Dagnat, Telecom Bretagne.

14
Références
[1] Model driven architecture specification. URL http://www.omg.org/
mda/specs.htm.

[2] Meta object facility (mof) specification. Version 1.4, April 2002.

[3] Meta object facility (mof) core specification. Version 2.0, January 2006.

[4] Wim Bast Anneke Kleppe, Jos Warmer. MDA Explained : The Model
Driven Architecture : Practice and Promise. Addison-Wesley, April
2003.

[5] Colin Atkinson. Metamodelling for distributed object environments. In

first International Enterprise Distributed Object Computing Workshop
(EDOC’97), Brisbane, Australia, 1997.

[6] Colin Atkinson. Supporting and applying the uml conceptual frame-
work. In P-A. Muller J. Bzivin, editor, The Unified Modeling Lan-
guage : Beyond the Notation, volume 1618 of Lecture Notes in Compu-
ter Science, pages 21–36. Berlin : Springer-Verlag, 1998.

[7] Colin Atkinson and Thomas Kuhne. The essence of multilevel meta-
modelling. In Proceedings of the 4th International Conference on The
Unified Modeling Language, Modeling Languages, Concepts, and Tools,
volume 2185 of Lecture Notes in Computer Science, pages 19–33. Sprin-
ger Verlag London, UK, 2001.

[8] Bhuvan Unhelkar Brian Henderson-Sellers. OPEN Modeling with UML.

Addison-Wesley, June 2000.

[9] Krzysztof Czarnecki and Simon Helsen. Classification of model trans-

formation approaches. In OOPSLA’03 Workshop on Generative Tech-
niques in the Context of Model-Driven Architecture, 2003.

[10] Cesar Gonzalez-Perez and Brian Henderson-Sellers. A powertype-based

metamodelling framework. Software and Systems Modeling, 5(1) :72–
90, August 2005.

[11] Henderson-Sellers and Gonzalez-Perez. Connecting powertypes and ste-

reotypes. Journal of Object Technology, 4(7) :83–96, September 2005.

[12] Michael Jackson. Some basic tenets of description. Software and Sys-
tems Modeling, 1(1) :5–9, September 2002.

[13] Mokrane Bouzeghoub Jacky Estublier Jean Marie Favre Jean Bzivin,
Mireille Blay. Rapport de synthese. In J. Bzivin L. Duchien R. Marvie

15
 S. Grard B. Baudry M. Bouzeghoub J-M. Jzquel M. Blay J. Estublier, J-
M. Favre and M. Riveil, editors, Action Specifique CNRS sur l’ingnierie
Dirige par les Modles. January 2005.

[14] Piero Fraternali Stefano Ceri Massimo Tisi, Frdric Jouault and Jean
Bzivin. On the use of higher-order model transformations. In Model
Driven Architecture - Foundations and Applications, volume 5562 of
Lecture Notes in Computer Science, pages 18–33. Springer Berlin /
Heidelberg, June 2009.

[15] Tom Mens and Pieter Van Gorp. A taxonomy of model transformation.
In International Workshop on Graph and Model Transformation (Gra-
MoT 2005), volume 152 of Electronic Notes in Theoretical Computer
Science, pages 125–142, March 2006.

[16] Frdric Fondement Pierre-Alain Muller and Benot Baudry. Modeling

modeling. In Model Driven Engineering Languages and Systems, vo-
lume 5795 of Lecture Notes in Computer Science, pages 2 – 16. Springer
Berlin / Heidelberg, September 2009.

[17] Eelco Visser. A survey of rewriting strategies in program transforma-

tion systems. In 1st International Workshop on Reduction Strategies in
Rewriting and Programming, WRS2001, volume 57 of Electronic Notes
in Theoretical Computer Science, pages 109–143, December 2001.

16