‫وزارة التعليم العالي والبحث العلمي‬

Mohamed Chérif MessadiaUniversity Souk-Ahras

Faculty of Science and Technology

Department of Mathematics and Computer Science

TITLE:

MODEL TARNSFORMATION APPROCHES AND TOOLS

Faculty
Informatique

Speciality

Software engineering
By:

Ben Sebihi Chaima

Module Teacher :Professeur.Abdelkrim AMIRAT

Module : model engineering

Year : 2019/2020
Abstract :

This modest work has enabled me to enrich my knowledge in transforming the model that
plays an important role in development software ,and that is by knowing all transformation
approaches and tools . i was also able to discover the environments for the creation of the
models and how to transform it .I touched on the study of both the atl and the gmf with their
structures and their own syntaxes with simple examples .

2
Table of contents :
Introduction ............................................................................................................................................ 4
1 Model transformations ........................................................................................................................ 5
1.1 Definition of notions of transformation ........................................................................................ 5
2 Transformation approaches and tools: ................................................................................................ 5
2.1 QVT ............................................................................................................................................... 5
2.1.1 Study and analysis .................................................................................................................. 5
2.1.2 QVT compliance points....................................................................................................... 6
Example (1) .............................................................................................................................. 6
2.2 Tefkat ........................................................................................................................................... 10
2.2.1 Study and analysis: ............................................................................................................... 10
2.2.2 Example (2) ...................................................................................................................... 15
2.3 Approches based on graph .......................................................................................................... 15
2.3.1 Study and analyze : .............................................................................................................. 15
2.3.2 AGG....................................................................................................................................... 15
2.3.3 ATOM3.................................................................................................................................. 15
2.3.4.1 Example (3) ................................................................................................................... 16
2.3.4 VIAYTRA ................................................................................................................................ 19
2.3.5 GReat .................................................................................................................................... 19
3 comparaison of various approches .................................................................................................... 20
3.1 Comparaison criteria ................................................................................................................. 20
4 GMF ................................................................................................................................................... 20
4.1 Example(4) .................................................................................................................................. 22
5 ATL .................................................................................................................................................... 25
5.1 Definition ..................................................................................................................................... 25
5.2 ATL language overview .............................................................................................................. 25
5.3 ATL module ................................................................................................................................. 25
5.4 OCL and ATL ............................................................................................................................... 26
5.5 Example(5) .................................................................................................................................. 27
Conclusion ............................................................................................................................................ 33
References ........................................................................................................................................... 34

3
Introduction
In the context of model-driven software engineering, model transformation is an activity
that is playing an increasingly important role in the development cycle: code generation,
maintenance, code optimization, composition aspects, reverse engineering, etc. So the model
transformation languages represent first-rate components of a development environment.[8]
This research i will present a state of the art of model transformation languages in the
context of model engineering. Regarding metamodeling and concrete syntaxes.
In this paper i will do a research about transformation approaches and tools , such as qvt
tefkat and the approaches based on graphs as atom3 ,agg.. all of them with a simple example .
Also , I will search about graphical modeling framework and how to do it ,with the main
levels in it and I have do a simple result at the end , then Iwill study atl as language of
transformation , a syntaxe and then I will study atl as language of transformation , how is it
the syntaxe of this language in addition to that, then I studied atl as language of
transformation , how is it the syntaxe of this language in addition to that ,i studied the
importence of ocl in atl and what the relation between them .

4
1 Model transformations
Model transformations are at the heart of the model-driven engineering approach. The
principle of model transformations is widely accepted and interests both researchers and
manufacturers. But there is not yet a real standard which highlights the implementation of a
process or chain of transformation. This is why we find in the literature multiple proposed
approaches (Smart QVT , ATL , Kermeta ). [1]
1.1 Definition of notions of transformation
To perform model transformations, models must be expressed in a certain language (for
example, UML for design models, Java for source code models). This language of modeling
itself being defined using a metamodel. Starting from the source and target metamodels of
transformation, there are two types of transformation : endogenous and exogenous. A
transformation is said to be endogenous if the models involved come from the same
metamodel. But when the source models and targets are of different metamodels, the
transformation is said to be exogenous or even translation. These two transformation
categories can be subdivided as follows:[1]
Endogenous transformations and Exogenous transformations :
Endogenous transformations are transformations between models expressed in the same
language. Exogenous transformations are transformations between models expressed using
different languages. For example, in a process conforming to the OMG Model Driven
Architecture, a platform-independent model might be transformed into a platform-specific
model by an exogenous model transformation.[8]
Another important factor to consider in transformations is the level of abstraction.A
distinction is made between horizontal and vertical transformations. A transformation
horizontal is a transformation where the source and target models are of the same level of
abstraction. In contrast, in a vertical transformation, the models involved are of different
levels of abstraction.[8]
2 Transformation approaches and tools:
There is many approaches such as :

2.1 QVT:

2.1.1 Study and analysis

The operational context of QVT is that which was presented with MOF 2.0 as metametamodel
and the QVT metamodel in place of MMT. QVT's abstract syntax is de ned by this
metamodel. Three sub-languages for the transformation of models are defined there. OCL 2.0
is used to navigate the models. Creation of views on models is not explicitly addressed in the
recommendation. The three sub-languages of QVT collectively form a hybrid transformation
language: with declarative and imperative constructions. These languages are called
Relations, Core and Operational Mappings. They are organized in an architecture presented .
The Relations and Core languages are both declarative but placed at different levels of
abstraction. The recommendation defines their concrete textual syntaxes as well as their
abstract syntaxes.[1]

5
In addition to that , Relations has a graphical syntax. Operational Mappings is an imperative
language that extends Relations and Core.Core language is declarative and simpler than
Relations. Definitions of written transformations in Core tend to be longer than those,
equivalent, written in Relations. The links of traceability are treated as elements of ordinary
models. The developer is responsible for their creation and use. One of the goals of Core is to
provide a basis for specifying the Semantics of Relations. The semantics of Relations is given
as a Relations transformation to Core. This transformation can be written in Relations.[1]
Operational Mappings Extends Relationships with Imperative Constructions and OCL
Constructions with side effects. The basic idea is that the patterns of objects speci ed in
relationships are instantiated using imperative constructs. In this way, the relations defined
declaratively are imperatively implemented. The Operational Mappings syntax provides the
common constructs of imperative languages (loops, conditional statements, etc.).[1]
The black box mechanism allows you to plug in and execute external code during the
execution of a transformation. This mechanism allows the implementation of complex
algorithms in any language and allows reuse of existing libraries.[1]

Figure1 The layered architecture of QVT's sub-languages

2.1.2 QVT compliance points
The dimension of languages defines three levels corresponding to the three languages of
QVT: Core, Relations and Operational Mappings. If a tool is confomed to a certain level, it
means that it is able to execute transformations written in the corresponding language.[1]
The interoperability dimension concerns the format in which a transformation is expressed. It
defines four levels:
Execution of the syntax. A tool can read and execute transformations written with the
concrete syntax given in the QVT recommendation.[1]
Running the XMI. A tool can read and execute serialized transformations with XMI rules .
The QVT transformations indeed conform to the QVT metamodel and XMI.[1]
Export syntax. A tool can export the transformations into the concrete syntax of the
corresponding language.[1]
Export of XMI. A tool can export the transformations in XMI format.[1]

Example (1)
-transform elements A to B by adding the sentence = student in MSII Ben MSiK on the
elements.

6
-after we create a project named transforQVT we create an ecore model as follow:

Figure 2 diagram model

Figure 3 ecore model

7
-secondly we create an operational QVT project named ABC project ,then we complete the
code of transformation.qvt as follow :

Figure 4 code transformation in qvt

-go back to the first object precisely ecore model and crate a dynamic instance named absMSI
,then we create our own model as follow :

Figure 5 abcMSII model

-thirdly go back to qvt project, run qvt configuration as follow :

8
 Figure 6 run configuration
-after run configuration we obtain the new model as follow:

Figure 7 resultMSII model

9
2.2 Tefkat
2.2.1 Study and analysis:
The Tefkat language is declarative ,logic-based ,and defined in terms of a MOF metamodel .
It has been specifically designed to address both the OMG ‘s QVT REP and additional
requirements identified as a result of a series of experiments with different transformation
language approaches.[1]
Models of tefkat are named extents, There are three types of extents: source, target and
traceability. Source extents are constructed from source models of the transformation. They
can only be navigated by rules (i.e. they are read-only). Target extents are composed of model
elements created during the execution of the transformation. They are write-only. A
traceability extent is a special extent which can be both navigated and modified by the
transformation rules. Its purpose is to maintain the traceability links between the source and
target extents.[9]
The declarative and unidirectional transformation rules are the basic modularization unit in
Tefkat. They have two parts formed by the reasons. Patterns can be defined separately and
used in several rules by referencing them by name. Patterns can refer to each other and be
recursive. The patterns are either recognized on the source extents and they select thus
elements on the basis of certain constraints or they are used to create or ensure the existence
of model elements in the target extents.[1]
A transformation specification is normally stored in a single file with the suffix .qvt. This file
starts with a line of the form:
def
TRANSFORMATION name_ : source_ [, source_]* -> target_ [, target_]*

-Import :

In order for the transformation engine (and also the parser) to be able to resolve class
names, you must specify the set of models that define those types. This is done with
an import statement which has the form:[9]

def
IMPORT uri

Generally, the uri will be of the form http://... or platform:/resource/... or file:/... and
should resolve to an EMF ECore instance.[9]

It is normal that you would include an import statement for each source model and each
target model and for the tracking model (if you use one).[9]

if the Ecore model you are importing has been loaded as a plugin then you should use
the URI to reference the model rather than a URL that points to the ECore file.[9]

-Rules :

are named and consist of a number of (optional) sub-parts: forall, where, make, set,
and linking, and have the following form:[9]

10
 def
RULE name_
FORALL class_ variable_
WHERE condition
MAKE ( class_ variable_ FROM name_ ( expressions )
| template_name_ ( expressions )
)
SET path = expression
LINKING tracking_ WITH name_ = expression
;

We have omitted fomally indicating where repeated elements may occur in the above for
the sake of clarity. Each of the sub-parts forall, make, and set may contain repeated
elements separated by commas. For example:[9]

FORALL Person p, Account a

-Patterns:

are like rules, but can only match things so are limited to forall and where sub-parts. As
well as being named, they also have one or more variables nominated as parameters.[9]

def
PATTERN name_ ( variables_ )
FORALL class_ variable_
WHERE condition

-Templates:

are like rules, but can only create or set things so are limited to make, set,
and linking sub-parts. As well as being named, they also have one or more variables
nominated as parameters.[9]

def
TEMPLATE name_ ( variables_ )
MAKE class_ variable_
WHERE condition
LINKING tracking_ WITH name_ = expression

2.2.2 Example (2)

Transformation uml to relational using tefkat.
-Create the source and target metamodels "simpleuml.ecore" and "relational.ecore" and save
them in the "models" folder.

11
 Figure 8 uml metamodel

Figure 9 relational metamodel

-Create a new file called "uml2rel.qvt" and save it in the "transformations" folder.This
version, "uml2rel2.qvt", is the same transformation but using the alternate object literal
syntax.

12
TRANSFORMATION uml2rel : uml -> rel

NAMESPACE http://simpleuml
NAMESPACE http://relational

// Produces a Table and Key for each persistent UMLClass.

//
RULE Class2Table(c, t, k)
FORALL UMLClass c
WHERE c.kind = "persistent"
MAKE Table t, Key k
SET t.name = c.name, t.key = k,
k.name = c.name
;

// Produces Columns belonging to a Table for

// each persistent UMLClass with storable Attributes.
//

RULE Attr2Column(c, a, t, k, col)

EXTENDS Class2Table(c, t, k)
FORALL Attribute a
WHERE hasAttr(c, a, n)
MAKE Column col FROM c4a(c,a,n)
SET col.name = n,
t.column = col
;

// Immediate Attributes of a UMLClass that are primary have

// their corresponding Column as part of the Table's Key.
//
ABSTRACT
RULE KeyColumns(c, a, t, k, col)
EXTENDS Attr2Column(c, a, t, k, col)
WHERE a.kind = "primary" AND
inhAttr(c, a)
SET col.belongsTo = k
;

// An Attribute is "storable" if it is a simple type

(PrimitiveDataType),
// or it is UMLClass-valued and that UMLClass is persistent.
//
PATTERN storable(A)
FORALL Attribute A
WHERE
C = A.type AND
(
PrimitiveDataType C
OR
(UMLClass C AND A.type.kind = "persistent")
)
;

// A UMLClass "inherits" an Attribute if it owns it directly,

// or it has a superclass that "inherits" the Attribute.
//
// [Note - other's mapping examples ignore this, but what is a
13
// "class" model without inheritance?]
//
PATTERN inhAttr(C, A)
FORALL UMLClass C, Attribute A, UMLClass C2
WHERE
// A UMLClass "inherits" an Attribute if it owns it directly,
// or it has a superclass that "inherits" the Attribute.
//
// [Note - other's mapping examples ignore this, but what is a
// "class" model without inheritance?]
//
PATTERN inhAttr(C, A)
FORALL UMLClass C, Attribute A, UMLClass C2
WHERE
A.owner = C
OR
(C.parents = C2 AND inhAttr(C2, A))
;

// This pattern is used to handle so-called "complex types".

// A UMLClass "has" and Attribute with a fully qualified name
// if it "inherits" the attribute and the attribute is storable,
// or it "inherits" another UMLClass-valued attribute for which the
// UMLClass is not persistent (ie a complex type) and that UMLClass
// "has" the attribute.
//
// This will cycle if two non-persistent UMLClasses transitively
// reference each other.
//
PATTERN hasAttr(C, A, N)
FORALL UMLClass C, Attribute A
WHERE
(
inhAttr(C, A) AND
storable(A) AND
A.name = N
)
OR
(
inhAttr(C, A2) AND
A2.type = C2 AND
UMLClass C2 AND
C2.kind != "persistent" AND
hasAttr(C2, A, N2) AND
N = append(A2.name, append("_", N2))
)
;

14
2.3 Approaches based on graph transformation:

2.3.1 study and analyze :

The graph transformation languages operate on a graph by rewriting it. The execution of a
transformation is composed of steps operating on a current graph. This current graph is
initially the source graph then evolves at each step. Each step corresponds to the application
of a rule. When no rule can no longer be applied, the current graph corresponds to the target
graph.[10]
Each rule is made up of a left part to be recognized in the current graph and a right part which
defines the changes to be made. In general, more than one rule is applicable to the current
graph.[1]
The choice of the rule to apply can be non-deterministic or be guided by: priorities, a control
flow, an explicit ordering of the rules, etc. Each rule can also have conditions Since the
models are graphs, these approaches can be used to transform models.Some of them do not
use a DE or MOF metamodel, but translations can generally be carried out. Parts of the
current graph conform to the source metamodel while other parts conform to the target
metamodel. In addition, the traceability links between source and target elements are also
represented by elements of the current graph. This means that the current graph conforms to a
common metamodel composed of the source and target metamodels as well as the elements
used to link the target elements to the source elements.[10]

2.3.2 AGG
is a development environment for graph transformation systems supporting an algebraic
approach to graph transformation. This approach is based on formal foundations. The source
and target metamodels and the common metamodel are represented by typed graphs. Graphs
can also be assigned using Java code: their elements can be decorated with pieces of code.
Transformations can be performed in two different modes. The first one is called “mode
interpretation ”and corresponds to the automatic application of the rules. This application is
not deterministic and continues until no rules can be applied. If a specific order of application
is required, rules can be grouped into ordered layers. The rules contained in a layer data are
only applied once a x point has been reached in the previous layer. In the second mode, a user
explicitly launches the application of each rule.[2]
2.3.3 ATOM3

AToM uses triple-graph grammars to specify transformations . The approach is similar to

AGG’s except that there is a clear separation between source, target and correspondence
graphs and the correspondence graph is untyped. Rule execution can be controlled by
specifying priorities.
Again, owing to its formal foundations it is possible to check transformations for certain
properties as in AGG. Unlike AGG, AToM is designed to facilitate change propagation
using its correspondence structure. However, again the transformations are essentially uni-
directional and there is no notion of bi-directional consistency checking. As a result, it is not
possible to propagate deletions using the same set of rules. [1]

15
 Figure 10 transformation in atom3.
2.3.3.1 Example(3) :
- Initial setup, I assume you've saved this model, given it a visual representation, named it
as QuickTut after pressing the EDIT button, and generated it.

Figure11 metamodel in atom3

-A common extension to an AToM3 formalism is a code generator, simulator, analyzer, etc.
To do this requires traversing the internal graph structure and creating a button so that we can
trigger it. Step 1 is to open your favourite code editor (*cough* Eclipse *cough*) and create a
file called "tutorialPrettyPrinter.py" with the following inside:

16
-Create a button to trigger the graph traverser. Start a fresh copy of AToM3, file open (Ctrl-
O), choose *_META.py as the filetype, and find the generate buttons model for your
formalism.

Figure create a button in atom3

-The buttons model looks something like this:

17
 Figure 12 after create a button
- You can type a Python code here, however the dialog box is not the worlds foremost IDE
and will not aid you in your debugging efforts! Type in the following code to import and run
the "real" code:

Figure13 tap a python code

-Save the buttons model. To make the changes take effect, you must now restart AToM3.

-Open the generated formalism. F3 then QuickTut_META.py , draw some instances of the
classes and associations, then press the graph traversal button. The screen grab below shows a
few things:
a) The traverser did do the whole graph

18
b) The associations were traversed first!
c) The set attribute worked (i.e.: hash('Quick') = -809163688 in Python). However notice how
the graphics were NOT updated. How do we fix that? Turns out the line commented out in
the traverser code given in step 2 was important, so uncomment:

Figure14 the result of transformation

2.3.4 VIATRA :
is a unidirectional transformation language mainly based on graph transformation techniques.
It is not based on MOF or Ecore metametamodels. The language operates on models
expressed using the VPM modeling approach . In this approach, it is possible to have an
arbitrary number of modeling levels and the typing relationship between model elements and
metamodel elements is explicitly represented.[1]
We can consider VIATRA as a hybrid language. The transformation rule language is
declarative but the rules cannot be executed without a speci ed execution strategy
imperatively. The language also allows the generation of code using generation patterns.[1]
2.3.5 GReAT
GReaT is a model transformations tool developed at Vanderbilt university . The
transformation specification language is divided into three parts consisting of a pattern
specification language that specifies patterns using UML class diagrams, a graph
transformation language that specifies a transformation as a set of productions, and a control-
flow language that provides control structures to specify production .[10]
A production is a triple consisting of a pattern graph, a guard that specifies the applicability
condition, and an attribute mapping that specifies at-tribute value assignments. the
transformations are essentially uni-directional and there is no support for bi-directional
consistency checking. As a result, it is not possible to propagate dele-tions using the same set
of productions. In addition, even though GReaT also pro-vides correspondence structure, it is
not clear if it can support at least some limited change propagation (additions and attribute
value changes) as its control behavior is quite complex.[1]

19
3 Comparison of various transformation approaches
3.1 Comparison criteria
- Consistency checking: Models need to be reconciled periodically to bring them up to a
mutually consistent state.
- Change propagation: The inconsistencies can then be resolved in one of two ways: 1. Tool
assisted propagation where a tool automatically propagates changes from one model to the
other.and 2.Manual propagation.
- Bi-directional transformations: suppose we have a legacy system that needs to be
modernized into an object-oriented system with additional functionality.

Figure14 Comparison of various transformation approaches

4 GMF transformation
Creating a model conforming to a meta-model is done in two ways:
- Instantiate the metamodel and have a model in XMI form,
- Generate a graphic editor from the metamodel by using the GMF to allow the graphic
creation of models that conform to this metamodel.

20
GMF is a framework for developing domain specific languages. GMF is built on the Eclipse
Modeling Framework (EMF) [3] and the Graphical Editing Frame-work (GEF) [4]. In the
context of GMF, EMF is used to define the meta model or abstract syntax of languages
(expressed in Ecore), and for generating code for creating, editing, and accessing models.
GEF is a framework that supports the development of graphical editors. In the context of
GMF, GEF is used to implement the concrete graphical syntax of languages and for editing of
concrete syntax.[4]

Figure.15 Transformation in GMF

The transformations of GMF are illustrated in Figure , we distinguish between 4 different

levels:[4]
The meta model level (level 0):This level contains the meta model which is the basis of code
generation. The meta model used by GMF must be stored in a format called Ecore.
The configuration level (level 1). This level contains the configuration model which is used
by the GMF transformation (this is not used by the EMF trans-formation). The configuration
model consists of three files: one file which is used to specify the shapes of the graphical
constructs of the language (.gmfgraph),one file which specifies the language constructs which
should appear in the tool palette of the language editor (.gmftool), and one file (.gmfmap)
which mapsthe items of the tool palette (defined in .gmftool ) to the graphical language
constructs (defined in .gmfgraph) and to the meta model elements.
The generator level (level 2). This level contains the code generator models for both the
EMF and the GMF transformations. Both generator models contain a number of parameters
that allows the user to customize the source code generated from the generator models
The source code level (level 3). This level contains the source code. Herew e distinguish
between:
–EMF code generated by the EMF transformation;
–GMF code generated by the GMF transformation, which makes use of the EMF code as well
as the GEF framework;
–modified GMF code, i.e. generated GMF code which has been modified after generation

21
4.1 Example (4)
Java source to table :
-The JavaSource to Table example describes a transformation from a Java source code to a
table which summarizes how many times each method declared in the Java source code is
called within the definition of any declared method
-we create an ecore model as follow

Figure16 java source meta model

-after we do all the steps in dashboard we obtain the stub as follow:

22
 Figure17 After generation
-then run the configuration and create a project named javasourcegmf ,after this we create a
default java source model and we obtain a palette to draw it :

Figure18 java source model

-The same steps to generate a table mode

23
Figure metamodel of a table

Figure19 table model

Figure20 table model

24
5 ATL
5.1 Definition
ATL (Atlas Transformation Language) is a model transformation language and toolkit
developed by the Atlas group (INRIA & LINA). In the field of Model-Driven Engineering
(MDE), ATL provides ways to produce a set of target models from a set of source models.
Developed on top of the Eclipse platform, the ATL Integrated Development Environment
(IDE) provides a number of standard development tools (syntax highlighting, debugger, etc.)
that aim to ease the development of ATL transformations.[6]
5.2 ATL Language Overview
‘’ATL is a hybrid transformation language. It contains a mixture of declarative and imperative
constructs. The encouraged style is declarative. ATL transformations are unidirectional,
operating on read-only source models and producing write-only target models. A bidirectional
transformation is implemented as a couple of transformations: one for each direction. During
the execution of a transformation the source model may be navigated but changes are not
allowed to it. The target model cannot be navigated. Source and target models for ATL may
be expressed in the XMI OMG serialization format. Source and target metamodels may also
be expressed in XMI or in the more convenient KM3 notation.’’[6]
5.3 ATL modules
Its structure is made up of a header section, an optional import section, a set of helpers and a
set of rules.[6]
5.3.1 The header section
The header section defines the name of the transformation module as well as the names of the
variables corresponding to the source and target models.
header is defined as follows:
module MMa2MMb;
create Mb : MMb [from|refining] Ma : MMa ;
5.3.2 The import section
This section is optional, it allows to declare the ATL libraries which must be imported. The
syntax of the import section is defined as follows:
uses nom_bibliothèque;
5.3.3 helpers
The ATL functions are called helpers according to the OCL standard (Object Constraint
Language (OCL)) on which ATL is based. OCL defines two kinds of helpers: operation and
attribute.
-The syntax of an operation helper is defined as follows:
helper [context type_du_contexte]? def : nom_du_helper
( nom_paramètre1 : type_paramètre1 , nom_paramètre2 : type_paramètre2) :

25
type_de_retour = expression;
-The syntax of an attribute helper is defined as follows:
helper [context type_du_contexte]? def : nom_du_helper : type_de_retour =
expression;
5.3.4 rules
The language includes three types of declarative rules and one type imperative rules.
-Standard rules (Matched rules): They constitute the core of the declarative transformation.
They are called only once for each tuple corresponding to their input patterns found in the
source models.
Exp:
rule rule_name {
from
in_var : in_type [( condition )]?
[using { var1 : var_type1 = init_exp1;
...
varn : var_typen = init_expn;}]?
to
out_var1 : out_type1 (bindings1),
...
out_varn : out_typen (bindingsn )
[do { action_block }]?
}
-Lazy rules: They look like standard rules, thedifference that they are only triggered by other
rules. They are applied to each tuple as many times as they are referenced.
- The unique lazy rule: Identical to the lazy rules not unique, with the difference that they are
applied only once for each tuple.
-The called rules: They provide the programming styleimperative. They can be seen as
special helper. They must be explicitly triggered.
5.4 Ocl and atl
Since the OCL standard is omnipresent in ATL programs, it is worth while introducing them right at
the beginning. ATL is designed and implemented with respect to the OCL standard. Derivations from
the standard are indicated with a specific remark.[6]

26
Model elements are defined in the source and target metamodels. Most metamodels have classes. In
ATL the notation "Metamodel!Class" is used to be able to differentiate classes of different
metamodels. Hence, it is possible to refer to several metamodels in the same program in ATL. The
latter is not the case in OCL. There are different OCL operations to treat and analyze classes:

• The operation oclIsTypeOf() checks if a given instance is an instance of a certain type (and not of
one of its subtypes or of other types).

• The operation oclIsKindOf() checks if a given instance is an instance of a certain type or of one of
its subtypes.

• The operation allInstances() returns you all instances of a given Type.

• The operation oclIsUndefined() tests if the value of an expression is undefined (i.e. if an attribute
with the multiciplicity zero to one is void or not. Please note: attributes with the multiplicity n are
often represented with collections, which may be empty and not void).[9]

5.5 Examples (5)

Example 1 : JavaSource to Table
The JavaSource to Table example describes a transformation from a Java source code to a
table which summarizes how many times each method declared in the Java source code is
called within the definition of any declared method. A XML-based format, inspired from the
JavaML , has been developed to encode all interesting information available in the Java
source code. We use, for this transformation, a very basic abstract Table model which may be
easily mapped to existing table representations (XHTML, ExcelML, etc.).

27
 figure22 meta model of java source

Figure23 metamodel of table

-atl code transformation

28
-- @path Table=/JavaSource2Table/metamodel/Table.ecore
-- @path JavaSource=/JavaSource2Table/metamodel/JavaSource.ecore

module JavaSource2Table;
create OUT : Table from IN : JavaSource;

------------------------------------------------------------------------------
-
-- HELPERS -------------------------------------------------------------------
-
------------------------------------------------------------------------------
-

-- This helper builds the sequence of all method definitions in all existing
-- classes.
-- Built sequence is ordered according to the couple (class_name,
method_name).
-- RETURN: Sequence(JavaSource!MethodDefinition)
helper def: allMethodDefs : Sequence(JavaSource!MethodDefinition) =
JavaSource!MethodDefinition.allInstances()
->sortedBy(e | e.class.name + '_' + e.name);

-- This helper builds the content of the table cell associated with the
context
-- MethodDefinition (row) and the input MethodDefinition (column).
-- The computed value corresponds to the number of calls of the second method
-- within the first method definition.
-- CONTEXT: JavaSource!MethodDefinition
-- IN: JavaSource!MethodDefinition
-- RETURN: String
helper context JavaSource!MethodDefinition
def : computeContent(col : JavaSource!MethodDefinition) : String =
self.invocations
->select(i | i.method.name = col.name
and i.method.class.name = col.class.name)
->size();

29
------------------------------------------------------------------------------
-
-- RULES ---------------------------------------------------------------------
-
------------------------------------------------------------------------------
-

-- Rule 'Main'
-- This rule generates the Table as well as its first row.
-- First row cells contain the different defined method, in the format
-- 'class_name.method_name', ordered by the value of the build string.
rule Main {
from
s : JavaSource!JavaSource

to
-- Table is composed of the first row + data rows
t : Table!Table (
rows <-
Sequence{first_row,
thisModule.allMethodDefs
->collect(e |
thisModule.resolveTemp(e, 'row'))
}
),
-- First row is composed of the first column + title columns
first_row : Table!Row (
-- cells <- Sequence{first_col, title_cols}
cells <- Sequence{first_col, thisModule.allMethodDefs ->
collect(md | thisModule.TitleCols(md))} -> flatten()
),
-- First column empty
first_col : Table!Cell (
content <- ''
)

-- Former version, with distinct ... foreach

--
--Title cols = 'class_name.method_name'
--title_cols : distinct Table!Cell
-- foreach(mDef in
thisModule.allMethodDefs)(
-- content <- mDef.class.name + '.' + mDef.name
--)
}

name').

30
unique lazy rule TitleCols {
from
md: JavaSource!MethodDefinition
to
tFilled: Table!Cell (
content <- md.class.name + '.' + md.name
)
}

-- Rule 'MethodDefinition'
-- This rule generates the content of the table, including the first cell of
-- each row, which identifies a method (format 'class_name.method_name').
rule MethodDefinition {
from
m : JavaSource!MethodDefinition

to
-- Rows are composed of the first (title) cell + data cells
row : Table!Row (
cells <- Sequence{title_cel, thisModule.allMethodDefs ->
collect(md | thisModule.DataCells(md, m))} ->
flatten()
),
-- Title cell = 'class_name.method_name'
title_cel : Table!Cell (
content <- m.class.name + '.' + m.name
)
-- Data cells = nb of calls of each method within a method
definition
-- cels : distinct Table!Cell foreach(mDef in
thisModule.allMethodDefs)(
-- content <- m.computeContent(mDef).toString()
-- )
}

lazy rule DataCells {

from
md: JavaSource!MethodDefinition,
m: JavaSource!MethodDefinition
to
cell: Table!Cell (
content <- m.computeContent(md).toString()
)
}

-before create file atl we create a java source model as follow :

31
 Figure24 java source model
-after run configuration we obtain table model as follow :

Figure 25 table model

32
Conclusion :
This paper presented different approaches to transformations. These are QVT, broken down
into Relations, Core and Operational Mappings, Tefkat and three approaches based on graph
transformation: VIATRA2, GReAT and AGG. These different languages were then compared
with each other, also I presented gmf and atl .
I conclude that model transformation plays an important role in model-driven engineering
(MDE) . The research efforts by the MDE community have produced various languages and
tools for automating transformations between different formalisms using mapping rules.
These transformation rules can be implemented using general programming languages such as
Java or C#, graph transformation languages like AGG and the VIsual Automated model
TRAnsformations (VIATRA) , or specific languages such as ATLAS Transformation
Language (ATL) and the Query/View/Transformation (QVT) . Sometimes, transformations
are based on invariants (preconditions and postconditions specified in languages such as the
SObject Constraint Language (OCL) ).

33
Reference:
[1] https://arxiv.org/pdf/these Contribution à l'étude des langages de transformation de
modèles
[2 ] AGG Homepage. http://tfs.cs.tu-berlin.de/agg
[3] A. Agrawal, G. Karsai and F. Shi. Graph Transformations on Domain-Specific Models.
Under consideration for publication in the Journal on Software and Systems Modeling,
2003.See:http://www.isis.vanderbilt.edu/publications/archive/Agrawal_A_11_0_2003_Grap_
Tran.pdf
[4] Eclipse project: GMF - Graphical Modeling Framework. http://www.eclipse.org/gmf
[5]https://www.researchgate.net/publication/221137711_An_Evaluation_of_the_Graphical_
Modeling_Framework_GMF_Based_on_the_Development_of_the_CORAS_Tool
[6] http://www.eclipse.org/atl/documentation/old/ATL_Flyer_Normal_Version.pdf
[7] https://arxiv.org/pdf/1207.
[8] https://en.wikipedia.org/wiki/Model_transformation
[9] http://tefkat.sourceforge.net/language_intro.html
[s10]
https://www.researchgate.net/publication/220054420_The_Graph_Rewriting_and_Transform
ation_Language_GreAT

34