Frédéric Jouault (Ed.)
Model Transformation with ATL
1st International Workshop, MtATL 2009
Nantes, France, July 8-9, 2009
Preliminary Proceedings

Copyright
c© 2009 for the individual papers by the papers' au-
thors. Copying permitted for private and academic purposes.
Re-publication of material from this volume requires permis-
sion by the copyright owners. This volume is published by its
editor.

Preface
Model transformation is an essential operation in Model-Driven Engineering.
It may be used to generate lower-level code from higher-level models, but its
application scope has now gone beyond Model-Driven Development scenarios.
The 1st International Workshop on Model Transformation with ATL aimed at
showing new applications for model transformation, as well as at improving the
technology. The papers published in these proceedings and the presentations
given during the workshop push back the boundaries of Model-Driven Engineer-
ing, and more particularly of model transformation with ATL. Some of these
works present original applications of model transformation to solve modeling
problems like measuring or checking models, testing model transformations, but
also to solve problems in other technologies (e.g., providing interoperability be-
tween non-modeling tools). Other works look at how ATL may be improved with
new or improved features like: traceability, transformation chaining, QVT com-
patibility, and direct support for UML profiles in order to support even more
advanced scenarios. The workshop started with a guest talk on the definition
of the meaning of models using model transformation. This talk provided an
enriching introduction, which concluded with a challenge-oriented view of the
workshop program. Finally, I thank all who made this workshop possible: the
program and organization committees, the reviewers, our guest speaker, and last
but not least the authors.
July 2009
Frédéric Jouault

Organization
MtATL 2009 was organized by the AtlanMod INRIA & EMN joint team, Nantes,
France, and collocated with RMLL 2009 (10th Libre Software Meeting).
Program Chair
Frédéric Jouault AtlanMod (INRIA & Ecole des Mines de Nantes)
Local Organization Committee
Jean Bézivin AtlanMod (INRIA & Ecole des Mines de Nantes)
Hugo Brunelière AtlanMod (INRIA & Ecole des Mines de Nantes)
Benoît Combemale AtlanMod (INRIA & Ecole des Mines de Nantes)
Guillaume Doux AtlanMod (INRIA & Ecole des Mines de Nantes)
Kelly Garcés Ascola & AtlanMod (INRIA & Ecole des Mines de
Nantes)
Jean-Sebastien Sottet AtlanMod (INRIA & Ecole des Mines de Nantes)
Massimo Tisi Politecnico di Milano
Program Committee
Patrick Albert ILOG, an IBM Company
Ronan Barrett Ericsson
María Cecilia Bastarrica Universidad de Chile
Raphaël Chenouard LINA, CNRS, Université de Nantes
Florent de Lamotte Universite de Bretagne Sud
Jean-Marie Favre University of Grenoble
Louis Feraud IRIT
Mathias Fritzsche SAP Research CEC Belfast
Dragan Gasevic Athabasca University
Martin Gogolla University of Bremen
Guillaume Hillairet Université de La Rochelle
Zhenjiang Hu National Institute of Informatics
Frédéric Jouault AtlanMod (INRIA & Ecole des Mines de Nantes)
Ivan Kurtev University of Twente
Stéphane Lacrampe Obeo
Ralf Laemmel The University of Koblenz-Landau
Denivaldo Lopes Federal University of Maranh
Frédéric Madiot MIA-SOFTWARE
Ed Merks Macro Modeling
Milan Milanovic School of Business Administration, University of Bel-
grade

Richard Paige University of York
Marc Pantel FéRIA/IRIT/INPT/ENSEEIHT/University
of Toulouse
Alfonso Pierantonio University of L'Aquila
Nicolas Rouquette Jet Propulsion Laboratory
Jesús Sánchez Cuadrado University of Murcia
Robert Tairas University of Alabama at Birmingham
Massimo Tisi Politecnico di Milano
Antonio Vallecillo University of Malaga
Bert Vanhooff DistriNet, K.U.Leuven
Juan Manuel Vara University Rey Juan Carlos
Dennis Wagelaar Vrije Universiteit Brussel
External Reviewers
K. Garcés
F. Thomas
A. Vignaga
V

Table of Contents
Guest Talk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Assigning Meanings to Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Antonio Vallecillo
ATL in Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Using ATL to define advanced and flexible constraint model
transformations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Raphaël Chenouard, Laurent Granvilliers, and Ricardo Soto
An Approach for Constructing a Domain Definition Metamodel with ATL 18
Vanea Chiprianov, Yvon Kermarrec, and Patrick D. Alff
Composite Transformations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Orchestrating ATL Model Transformations . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Jose E. Rivera, Daniel Ruiz-González, Fernando López-Romero,
and Antonio Vallecillo
Typing ATL Models in Global Model Management . . . . . . . . . . . . . . . . . . . . 47
Andrés Vignaga, and María Cecilia Bastarrica
Advanced Model Transformation Techniques . . . . . . . . . . . . 63
White-Box Coverage Criteria for Model Transformations . . . . . . . . . . . . . . . 63
Jacqueline McQuillan, and James Power
Advanced Traceability for ATL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Andres Yie, and Dennis Wagelaar
Leveraging Model Transformations by means of Annotation Models . . . . . 88
Juan Manuel Vara, Veronica Andrea Bollati, Belén Vela, and
Esperanza Marcos
ATL and Other Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Composing Models with Five Different Tools: a Comparative Study . . . . . 103
Juan Pedro Silva, Miguel De Miguel, Javier Fernández Briones,
and Alejandro Alonso
Achieving QVTO & ATL Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Alfons Laarman

Short Papers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
On Using UML Profiles in ATL Transformations . . . . . . . . . . . . . . . . . . . . . . 134
Manuel Wimmer, and Martina Seidl
Checking syntactic constraints on models using ATL model transformations 140
Skander Turki, Eric Senn, Dominique Blouin, Saadia Dhouib,
Jean-Philippe Diguet, and Johan Laurent
Mutation Analysis for Model Transformations in ATL . . . . . . . . . . . . . . . . . 145
Piero Fraternali, and Massimo Tisi
Towards Traceability support in ATL with Obeo Traceability . . . . . . . . . . . 150
Freddy Allilaire
UMLQualityAnalysis: UML models measurements with ATL . . . . . . . . . . . 154
Mathieu Vénisse
Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
VII

Assigning Meanings to Models
Antonio Vallecillo
GISUM/Atenea Research Group. Universidad de Málaga (Spain).
av@lcc.uma.es
Abstract. Why do we model? Apart from to generating code, models
can have (and should have) many different usages in the realm of Soft-
ware Engineering including, e.g., understanding and reasoning about the
system under study, simulating it, or analyzing its properties before the
system is built. For these tasks we need to be able to make questions
about the model, and therefore count on languages for expressing both
the models and the questions, at the right level of abstraction, and using
the appropriate notations. This talk discusses the need to count on dif-
ferent models to describe a system, using different languages, and how
semantics can be assigned to them using model transformations. Such
semantics define the "meanings" of models, making them amenable to
interpretation and analysis. These analyses can range from behavioral
simulation and formal reasoning (correctness, validation, model check-
ing) to more agile ones, such as the graphical visualization of models for
the detection of design anomalies, for instance.

Using ATL to define advanced and flexible
constraint model transformations
Raphae¨l Chenouard1, Laurent Granvilliers1, and Ricardo Soto1,2
1 LINA, CNRS, Universite´ de Nantes, France
2 Escuela de Ingenier´ıa Informa´tica
Pontificia Universidad Cato´lica de Valpara´ıso, Chile
{raphael.chenouard,laurent.granvilliers,ricardo.soto}@univ-nantes.fr
Abstract. Transforming constraint models is an important task in re-
cent constraint programming systems. User-understandable models are
defined during the modeling phase but rewriting or tuning them is manda-
tory to get solving-efficient models. We propose a new architecture al-
lowing to define bridges between any (modeling or solver) languages and
to implement model optimizations. This architecture follows a model-
driven approach where the constraint modeling process is seen as a set
of model transformations. Among others, an interesting feature is the def-
inition of transformations as concept-oriented rules, i.e. based on types
of model elements where the types are organized into a hierarchy called
a metamodel.
1 Introduction
Constraint programming (CP) systems must combine a modeling language and
a solving engine. The modeling language is used to represent problems with vari-
ables, constraints, or statements. The solving engine computes assignments of
variables satisfying the constraints by exploring and pruning the space of poten-
tial solutions. This paper considers the constraint modeling process as constraint
model transformations between arbitrary modeling or solver languages. It fol-
lows several important consequences on the architecture of systems and user
practices.
Constraint programming languages are rich, combining common constraint
domains, e.g. integer constraints or linear real constraints, with global constraints
like alldifferent, and even statements like if-then-else or forall. More-
over the spectrum of syntaxes is large, ranging from computer programming
languages like Java or Prolog to high-level languages intended to be more human-
comprehensible. This may be contrasted with the existence of a standard lan-
guage in the field of mathematical programming, which improves model sharing,
writing and understanding. The quest of a standard CP language is a recent
thread, dating back to the talk of Puget [15]. Another important concern is to
employ the best solving technology for a given model. As a consequence, a new
kind of architecture emerged. The key idea is to map models written with a
high-level CP language to many solvers. For instance within the G12 project,
2

Figure 5 depicts the ECLiPSe model resulting from an automatic transfor-
mation of the previous s-COMMA model. The problem is now encoded as a single
predicate whose body is a sequence of atoms. The sequence is made of the prob-
lem dimensions, the list of constrained variables L, and three statements resulting
from the transformation of the three s-COMMA classes. It turns out that parts
of both models are similar. This is due to the sharing of concepts in the un-
derlying metamodels, for instance constants, forall statements, or constraints.
However, the syntaxes are different and specific processing may be required. For
instance, the forall statement of ECLiPSe needs the param keyword to declare
parameters defined outside of the current scope, e.g. the number of groups G.
The treatment of objects is more subtle since they must not participate to
ECLiPSe models. Many mapping strategies may be devised, for instance map-
ping objects to predicates [16]. Another mapping strategy is used here, which
consists in removing the object-based problem structure. Flattening the prob-
lem requires visiting the many classes through their inheritance and composi-
tion relations. A few problems to be handled are described as follows. Impor-
tant changes on the attributes may be noticed. For example, the weeks array of
Week objects defined at line 9 in Figure 4 is refactored and transformed to the
WEEKS GROUPS PLAYERS flat list stated at line 5 in Figure 5. It may be possible to
insert new loops in order to traverse arrays of objects and to post the whole set
of constraints. For instance, the last block of for loops in the ECLiPSe model
(lines 27 to 39) has been built from the playOncePerWeek constraint zone of the
s-COMMA model, but there is two additional for loops (lines 21 and 22) since the
Week instances are contained in the weeks array. Another issue is related to lists
that cannot be accessed in the same way than arrays in s-COMMA. Thus, local
variables (Vi) and the well-known nth Prolog built-in function are introduced in
the ECLiPSe model.
4 Pivot metamodel and refactoring rules
The pivot model of a constraint problem is an intermediate model to be trans-
formed by rules. The rules may be chained to implement complex transforma-
tions. In the following, the pivot and some structural refactoring and optimiza-
tion rules are presented.
4.1 Pivot metamodel
Our pivot model has been designed to support as much as possible the constructs
present in CP languages, for instance variables of many types, data structures
such as arrays, record, classes, first-order constraints, common global constraints,
and control statements. We believe that it is better and simpler to establish a
general CP metamodel, while it is more complex to find a standard CP concrete
syntax.
Figure 6 depicts the metamodel associated to pivot models. A pivot model
is composed of a collection of elements, divided in three main concepts: types,
8

It can be highlighted that there is no ATL rule where the source pattern matches
elements being instances of CSPClass. Thus, they are implicitly removed from
models (obviously no rule creates class instances). The second transformation
removes records to get flattened variables (see Figure 8).
1 rule Model {
2 from
3 s : Pivot ! CSPModel
4 to
5 t : Pivot ! CSPModel (
6 name <− s . name ,
7 e lements <− s . e lements
8 }
9 rule Var iab le {
10 from
11 s : PivotCSP ! CSPVariable (
12 not s . mustBeDuplicated
13 )
14 to
15 t : PivotCSP ! CSPVariable (
16 name <− s . name ,
17 type <− s . type ,
18 domain <− s . domain ,
19 i s S e t <− s . i sSe t ,
20 array <− s . array
21 )
22 }
23 rule Variable2Record {
24 from
25 s : PivotCSP ! CSPVariable (
26 s . i sOb j e c t
27 )
28 to
29 t : PivotCSP ! CSPRecord (
30 name <− s . name ,
31 array <− s . array ,
32 e lements <− s . type . f e a tu r e s−>c o l l e c t ( f |
33 thisModule . dup l i c a t e ( f )
34 )
35 )
36 }
Fig. 7. An extract of ATL rules used to remove the concept of class in pivot models.
In Figure 7, the first rule (lines 1 to 8) is used to copy the root concept of
model. Most of other concepts are duplicated with similar rules like the the
second one (lines 9 to 22). The helper mustBeDuplicated is defined for each
CSPModelFeature and it returns true when: (1) the considered element is an ob-
ject variable (its type is a class) or (2) it is a feature of a class. Using the last
rule, object variables are replaced by records. The helper isObject returns true
only if the type of variables is a class. In this rule, features of variable classes
are browsed using OCL navigation (collect statement over s.type.features).
The rule duplicate is applied on each feature. This rule is lazy and abstract. It
is specialized for each CSPModelFeature concrete sub-concepts and it creates as
many features as it is called.
10

The second transformation processes records by replacing them by their set
of elements. This is easily done by collecting their elements from their container
as shown on Figure 8 at lines 7 to 11. The helper getAllElements returns the set
of CSPModelFeature within a record or a hierarchy of records.
1 rule CSPModel {
2 from
3 s : PivotCSP ! CSPModel
4 to
5 t : PivotCSP ! CSPModel (
6 name <− s . name ,
7 e lements <− s . elements−>union ( s . elements−>s e l e c t ( r |
8 r . oclIsTypeOf (PivotCSP ! CSPRecord )
9 )−> c o l l e c t ( r |
10 r . getAl lElements
11 )−> f l a t t e n ( ) )
12 )
13 }
14 rule RecordArray {
15 from
16 s : PivotCSP ! CSPRecord (
17 ( not s . array . oc l I sUnde f ined ( ) ) and
18 s . elements−>s e l e c t ( e |
19 e . oc l I sKindOf (PivotCSP ! CSPStatement )
20 )−> s i z e ()>0
21 )
22 to
23 t : PivotCSP ! CSPForall (
24 index <− i ,
25 c on s t r a i n t s <− s . elements−>r e j e c t ( e |
26 e . oc l I sKindOf (PivotCSP ! CSPTypedElement )
27 ) ,
28 i : PivotCSP ! CSPIndexVariable (
29 name <− s . name ,
30 domain <− d
31 ) ,
32 d : PivotCSP ! CSPIntervalDomain (
33 lower <− l ,
34 upper <− thisModule . dupl icateExpr ( s . array . n)
35 ) ,
36 l : PivotCSP ! CSPIntVal (
37 value <− 1
38 )
39 }
Fig. 8. Main ATL rules used to remove the concept of record in pivot models.
However, some other complex rules must be defined to process arrays of
records, (formerly arrays of object variables). Indeed, contained statements have
to be encapsulated in a for loop to take into account the constraints for all objects
in the array. This task is performed by the rule RecordArray which create a new
for loop over the record statements (lines 25 to 27). A new for loop requires also
a new index variables with its domain (lines 28 to 38).
Using the concrete syntax of s-COMMA, Figure 9 shows the result of this
refactoring step. The name of the variable at line 1 corresponds to the concate-
11

nation of all object variable names. The two for loops (lines 2 and 3) were created
from the arrays of objects using their name for index variables.
1 int set weeks g roups p laye r s [w∗g ] in [ 1 , 9 ] ,
2 f o ra l l weeks in [ 1 ,w] {
3 f o ra l l groups in [ 1 , g ] {
4 card ( weeks g roups p laye r s [ weeks∗w+groups ] )= g ,
5 . . .
6 }
7 }
Fig. 9. Extract of the social golfers pivot model after composition removal and enu-
meration removal transformations.
Enumeration removal During this refactoring step, enumeration variables are
replaced by integer variables with a domain defined as an interval from one to
the number of elements within the enumeration. Line 1 in Figure 9 shows the
result of this transformation on the enumeration called Name in the social golfers
model: the variable has an integer domain from 1 to 9 replacing the set of nine
values {a, b, c, d, e, f, g, h, i}. In the same way, occurences of CSPEnumLiteral are
replaced by their position in the sequence of elements of the enumeration type.
Other implemented refactoring steps Some other generic refactoring steps
have been implemented in ATL to handle some structural needs. They are not
detailed since their complexity is similar to the previous examples and to detail
all of them is not the scope of this paper.
– If statements can be replaced by one constraint based on one or two boolean
implications. For instance, if a then b else c becomes (a → b) ∧ (¬a → c).
– Loop structures can be unrolled, i.e. the loop is replaced by the whole set of
constraints it implicitly contains. Within expressions, the iterator variable
used by the loop structure is replaced by an integer corresponding to the
current number of loop turns.
– Expressions can be simplified if they are constants. Boolean and integer
expressions are replaced by their evaluation. Real expressions are not pro-
cessed, because of real number rounding errors. More subtle simplifactions
can be performed on boolean expressions such as a∨¬a that is always true.
Only atomic boolean elements are processed by this last step.
– Matrices are not allowed in all CP language, thus they can be replaced by one
dimension arrays. Their occurrences in expressions must also be adapted: the
index of the array is computed as follows: m[i, j] becomes m[j + (i ∗ ncols)],
where ncols is the number of columns of the matrix m.
– The ECLiPSe language does not allow some sort of expressions. For instance,
arrays of int sets cannot be accessed like other arrays with ‘[ ]’. Thus, an
12

improve the management of complex CP models transformation chains. Models
can be qualified to determine their level of structure and to automatically choose
the required refactoring steps according to the target language.
References
1. M. Barbero, F. Jouault, and L. Be´zivin. Model driven management of complex
systems: Impementing the macroscope’s vision. In 15th International Conference
on Engineering of Computer-Based Systems, 2008.
2. J. Be´zivin and F. Jouault. Using atl for checking models. In Proceedings of the
International Workshop on Graph and Model Transformation (GraMoT), Tallinn,
Estonia, 2005.
3. S. Brand, G. J. Duck, J. Puchinger, and P. Stuckey. Flexible, rule-based constraint
model linearisation. In P. Hudak and D. Warren, editors, Practical Aspects of
Declarative Languages, volume 4902 of LNCS, pages 68–83. Springer, 2008.
4. R. Chenouard, L. Granvilliers, and R. Soto. Model-driven constraint programming.
In ACM SIGPLAN PPDP, pages 236–246, Valencia, Spain, 2008.
5. A. M. Frisch, M. Grum, C. Jefferson, B. Mart´ınez Herna´ndez, and I. Miguel. The
design of essence: A constraint language for specifying combinatorial problems. In
IJCAI, pages 80–87, 2007.
6. A.M. Frisch, C. Jefferson, B. Martinez-Hernandez, and I. Miguel. The Rules of
Constraint Modelling. In IJCAI 2005, pages 109–116, Edinburgh, Scotland, 2005.
7. M. Fritzsche, H. Bruneliere, B. Vanhooff, Y. Berbers, F. Jouault, and W. Gilani.
Applying megamodelling to model-driven performance engineering. In 16th Annual
IEEE ECBS, San Fransisco, USA. April 13-16, 2009.
8. T. Fru¨hwirth. Constraint Handling Rules. Cambridge University Press, June 2009.
to appear.
9. L. Granvilliers and F. Benhamou. Algorithm 852: Realpaver: an interval solver
using constraint satisfaction techniques. ACM Trans. Math. Softw., 32(1):138–
156, 2006.
10. F. Jouault, F. Allilaire, J. Be´zivin, and I. Kurtev. Atl: A model transformation
tool. Science of Computer Programming, 72(1-2):31 – 39, 2008. Special Issue on
Second issue of experimental software and toolkits (EST).
11. F. Jouault, J. Be´zivin, and I. Kurtev. TCS: a DSL for the specification of textual
concrete syntaxes in model engineering. In Conference on Generative Programming
and Component Engineering (GPCE 2006), pages 249–254, 2006.
12. F. Jouault and I. Kurtev. Transforming Models with ATL. In MoDELS Satellite
Events 2005, volume 3844 of LNCS, pages 128–138. Springer, 2005.
13. N. Nethercote, P. J. Stuckey, R. Becket, S. Brand, G. J. Duck, and G. Tack. Miniz-
inc: Towards a standard cp modelling language. In C. Bessie`re, editor, 13th Inter-
national CP Conference, volume 4741 of LNCS, pages 529–543. Springer, 2007.
14. OMG. Model Driven Architecture (MDA) Guide V1.0.1, 2003.
http://www.omg.org/cgi-bin/doc?omg/03-06-01.
15. J.F. Puget. Constraint programming next challenge: Simplicity of use. In CP 2004,
LNCS 3258, pages 5–8.
16. R. Soto and L. Granvilliers. The design of comma: An extensible framework for
mapping constrained objects to native solver models. In IEEE ICTAI 2007, pages
243–250, 2007.
17. M. Wallace, S. Novello, and J. Schimpf. Eclipse: A platform for constraint logic
programming, 1997.
17

Networkname : EStringNode
Computername : EStringipAddress : EStringportNb : EIntsetPortNb (EInt)
Internet Routername : EStringipAddress : EStringconfigureIpAd... () : ...removeIpAd... () : ...
CE PE
VRFvrfName : EStringrouteDistinguisher : EStringconfigureVrf () : EIntremoveVrf () : EInt
VrfRouteTargetrouteTarget : EStringconfigureRt () : EIntremoveRt () : EInt
BgpIpv4AddressFamilyNeighborremoteAsNumber : EIntneighborIpAddress : EStringconfigureBgpNeighbor () : EIntremoveBgpNeighbor () : EInt
BgpRoutingProtocollocalAsNumber : EInt
InterfacenetMask : EStringattachVrf (VRF) : EIntdetachVrf (VRF) : EInt
innerNetworks0..*
nodes0..*
inLinks0..* outLinks
0..*
attachedToInterfaces1..*
vrfRouteTargets
1..*
familyNeighbors 1..*bgpRoutingProtocol
1..*
customerFacingInterface
1vrf 0..1 attachedVrf1
providerFacingInterface
1
Domain DefinitionMeta-Model (UML)Prototype(TOPCASED)
Fig. 2. Abstract Syntax of SGTSML
Program slicing, as defined by [9], applies a slicing criteria on a program to
compute a slice (i.e.; a subset of the source code). Model slices are as well defined
using a slicing criterion that is specified with predicates over the model’s features.
Consequently, model querying and model slicing in particular constitute a good
starting point for our approach. However, because we will change elements in the
output model (e.g.; for hierarchy shrinkage we will change the parent class in a
generalization relation), we need mechanisms more powerful than just querying,
we need model transformations.
As we mentioned in Sect. 1, we construct the DDMM by eliminating classes
and shrinking inheritance hierarchies from NALs expressed as UML class models.
We think that the most significant reductions will be due to hierarchy shrinkage.
Therefore, we are particularly interested in hierarchy shrinkage methods. A more
focused technique of program slicing is the class hierarchy slicing. An algorithm
for slicing class hierarchies in C++ programs is described in [10]. This algorithm
eliminates from an C++ class hierarchy the data and function members, classes
and inheritance relations that are unnecessary for ensuring that the semantics
of a program P that uses the hierarchy is maintained. However, this type of
algorithm is context-sensitive, as it needs the program P that uses the hierarchy.
The DDMM that we build is intrinsically context-free, as it has no knowledge and
should not depend on the future models that will be defined using it. Therefore,
such an approach is not suitable for us.
21

The example we chose to illustrate the NAL, LargeHierarchy, is presented
in Fig. 4. On one hand, an NAL’s components are entities with attributes but
no methods. The most frequent types of relation between these components are
association and generalization. On the other hand, the service designers describe
a service as a chain of calls to entities named capabilities, much as calls to
functions. Therefore, a preliminary operation of mapping the capabilities (some
hundreds) on the entities of the NAL (some tens of thousands) is done manually.
This results in some of the NAL’s classes having methods. They are represented
in LargeHierarchy by the classes B, C, E, F, G, H. These classes will be part of
the DDMM. We call this type of NAL classes, that after slicing appear in the
DDMM, generators.
PackagePackage
A
attributesoperationsclasses
C
attributesoperationsM2( )classes
M
attributesoperationsclasses
N
attributesoperationsclasses
O
attributesoperationsclasses
B
attributesoperationsM1( )classes
P
attributesoperationsclasses
X
attributesoperationsclasses
Q
attributesoperationsclasses
E
attributesoperationsM3( )M4( )classes
G
attributesoperationsM11( )classes
R
attributesoperationsclasses
F
attributesoperationsM10( )classes
H
attributesoperationsM12( )classes
srcdst
srcdst
srcdst
Generalization
Association
Fig. 4. Example of NAL: Large Hierarchy
23

The model transformation rules are presented, written in natural language,
in Sect. 4.1 and written in ATL, in Sect. 4.2. The output model resulted from
applying the model transformation rules on LargeHierarchy is presented in Fig.
5. We call it SmallHierarchy and it constitutes an example of DDMM. One
can observe that all classes from LargeHierarchy that have at least one method
(i.e.; B, C, E, F, G, H ) exist in SmallHierarchy too. The initial relations between
them (e.g.; the association relation from F and G and the generalization relation
between F and H ) also appear in the output model. The most interesting relation
in SmallHierarchy is the association from classes B and C, resulted from the
shrinkage of the initial hierarchy between A and B.
PackagePackage
C
attributesoperationsM2( )classes
B
attributesoperationsM1( )classes
E
attributesoperationsM3( )M4( )classes
G
attributesoperationsM11( )classes
F
attributesoperationsM10( )classes
H
attributesoperationsM12( )classes
src
dst
src
dst
srcdst
Generalization
Association
Fig. 5. Example of DDMM: Small Hierarchy
4.1 Model Transformation Rules
Our main idea for querying an NAL is to start from a set of initial generators (i.e.;
the classes that have at least one method) and select as generators other classes
that are related to the initial generators in a way that is relevant for service
designers. The types of relation between classes from NAL, that we consider
important for service designers, are association and generalization.
The rule to select the set of initial generators, in natural language:
1. Select all classes from NAL that have at least one method.
The rules for selecting associations, in natural language:
1. Select all direct associations from NAL that relate two generator classes.
2. We define the notion of least derived generator (ldSAG) as the generator
which, in a hierarchy that contain generators in a generalization relation, is
the highest in the hierarchy. Move association relations down in the hierarchy
(i.e.; towards the more derived classes) to the least derived generator.
24

6 to
7 at : UML! As soc i a t i on (
8 name<−as . name ,
9 package <− as . package ,
10 memberEnd<−memberLst
11 ) ,
12 memberLst : d i s t i n c t UML! Property fo r each ( asMember
in as . memberEnd . asSequence ( ) ) (
13 name<−asMember . name ,
14 type<−asMember . type )
15 }
The rule DirectAssociation uses the attribute allSags:
1 −−a t t r i b u t e s
2 he lpe r de f : a l l S a g s : Set (UML! Class ) =
3 l e t a l l C l a s s e s : Set (UML! Class ) = UML! Class .
a l l I n s t a n c e s ( ) in
4 a l l C l a s s e s−>s e l e c t ( i | i . ownedOperation−>notEmpty ( ) ) ;
1 r u l e moveAssocDownHierarchy{
2 −−moves an a s s o c i a t i o n
3 −−does NOT promote an element to an SAG
4 from
5 ps : UML! Property (
6 −−the source element should have i t s p a r t i c i p a n t in
a h i e ra r chy
7 i f ( ps . ldSagToMoveAssocDownHierarchyTo = ’ ’ )
8 −−the downHierarchy should have at l e a s t one SAG
9 −−(to s i m p l i f y the problem , I con s id e r here only
the ldSAGs )
10 then f a l s e
11 e l s e
12 i f ( ps . doesDownHierarchyContainSeveralLdSags ( ps .
ldSagToMoveAssocDownHierarchyTo ) )
13 −−the h i e ra r chy should have only one ldSAG
14 −−( i t can have a SAG on only one branch )
15 then f a l s e
16 e l s e t rue
17 e n d i f
18 e n d i f )
19 us ing {
20 targetLdSag : UML! Class = ps .
ldSagToMoveAssocDownHierarchyTo ;}
21 to
22 at : UML! As soc i a t i on (
26

15 l e t otherMemberEnd : UML! Property =
16 i f ( s e l f . a s s o c i a t i o n . memberEnd−>asSequence ( )−> f i r s t ( )
= s e l f )
17 then s e l f . a s s o c i a t i o n . memberEnd−>asSequence ( )−> l a s t ( )
18 e l s e s e l f . a s s o c i a t i o n . memberEnd−>asSequence ( )−> f i r s t
( )
19 e n d i f
20 in
21 thisModule . ldSags−>i t e r a t e ( ldSag ; has : Boolean = f a l s e
|
22 i f ( ldSag <> f i r s tLdSag )
23 then
24 i f ( ldSag . upperHierarchy−>i n c l u d e s ( otherMemberEnd .
type ) )
25 then true
26 e l s e has
27 e n d i f
28 e l s e
29 has
30 e n d i f ) ;
The helper doesDownHierarchyContainSeveralLdSags uses the attributes ld-
Sags and upperHierarchy, the latter using at its turn the helpers ancestors and
parents to navigate through the hierarchy:
1 he lpe r de f : ldSags : Set (UML! Class ) =
2 l e t sags : Set (UML! Class ) = thisModule . a l l S a g s
3 in sags−>s e l e c t ( sag | sag . upperHierarchy−>i t e r a t e (
4 i ; no tEx i s t s : Boolean = true |
5 i f ( sags−>i n c l u d e s ( i ) )
6 then notEx i s t s = f a l s e
7 e l s e notEx i s t s
8 e n d i f ) ) ;
9 −−sag . upperHierarchy−>exc lude sA l l ( sags ) ) ;
10
11 he lpe r context UML! Class de f : upperHierarchy : Set (UML!
Class ) =
12 s e l f . an c e s t o r s ( ) ;
13
14 he lpe r context UML! Class de f : a nc e s t o r s ( ) : Set (UML!
Class ) =
15 l e t pars : Set (UML! Class ) = s e l f . parents ( ) in
16 pars−>union (
17 pars−>i t e r a t e ( parent ; ances t : Set (UML! Class ) = Set {}
|
18 ancest−>union ( parent . an c e s t o r s ( ) ) ) ) ;
28

19
20 he lpe r context UML! Class de f : parents ( ) : Set (UML! Class )
=
21 l e t a l lGens : Set (UML! Class ) = s e l f . g e n e r a l i z a t i o n in
22 al lGens−>i t e r a t e ( gen ; par : Set (UML! Class ) = Set {} |
par−>union ( Set {gen . g ene ra l }) ) ;
The rules related to generalization are DirectGeneralization and markAs-
Sag:
1 r u l e D i r e c t G e n e r a l i z a t i o n {
2 from
3 gs : UML! Gene ra l i z a t i on (
4 gs . g ene ra l . ownedOperation−>notEmpty ( ) and gs .
s p e c i f i c . ownedOperation−>notEmpty ( ) )
5 to
6 gt : UML! Gene ra l i z a t i on (
7 genera l<−gs . genera l ,
8 s p e c i f i c <−gs . s p e c i f i c )
9 }
1 r u l e markAsSag{
2 −−promotes an element to an SAG
3 −−updates the allSAG and ldSAG l i s t s
4 −−c r e a t e s an a s s o c i a t i o n to the new SAG
5 −−c r e a t e s g e n e r a l i z a t i o n s to the new SAG ( i f nece s sa ry )
6 from
7 ps : UML! Property (
8 i f ( ps . ldSagToMoveAssocDownHierarchyTo = ’ ’ )
9 then f a l s e
10 e l s e
11 i f ( ps . doesDownHierarchyContainSeveralLdSags ( ps .
ldSagToMoveAssocDownHierarchyTo ) )
12 then true
13 e l s e f a l s e
14 e n d i f
15 e n d i f )
16 us ing {
17 otherMemberEnd : UML! Property =
18 i f ( ps . a s s o c i a t i o n . memberEnd−>asSequence ( )−> f i r s t
( ) = ps )
19 then ps . a s s o c i a t i o n . memberEnd−>asSequence ( )−> l a s t
( )
20 e l s e ps . a s s o c i a t i o n . memberEnd−>asSequence ( )−>
f i r s t ( )
21 e n d i f ;
29

4.3 Preliminary performance results
In order to have an idea of the performance of the transformation, we did some
preliminary tests. We used as machine a Dell Latitude E4300, with an Intel
Core2 Duo CPU P9300 @ 2.26GHz 1.58GHz, 3.45Go RAM, with Microsoft XP
SP3. As input model we used the model presented in Fig. 4, which we dupli-
cated several times to obtain a bigger model. Table 1 shows on each line a model
with increasing dimensions. The ’Factor’ column represents the number of times
the initial model has been duplicated. The column ’File’ represents the dimen-
sion of the input model file, in bytes. The columns ’Classes’, ’Associations’ and
’Generalizations’ represent the number of classes, associations and generaliza-
tions respectively contained by each model. The column ’Execution time’ repre-
sents the execution time, in seconds, of the transformation rules applied on each
model respectively. To measure the execution time we used the Eclipse facilities
(Run→Run Configurations, Advanced tab, and select ’Run mode only: print ex-
ecution times to console: 1) transformation only, and 2) total (including model
loading and saving)’; we mention that there was only one time printed at the
console). The result of under 3 minutes for a model containing approximately
20.000 entities encourages us to think that, when applied on industrial-scale
NALs, the transformation will have satisfactory execution times.
Crt. Factor File (B) Classes Associations Generalizations Execution time (s)
1 1 6,105 14 2 8 0.093
2 8 42,400 104 16 64 0.312
3 64 306,348 832 128 256 6.5
4 1,024 2,120,162 14,336 2,048 8,192 161.531
Table 1. Performance results
5 Lessons Learned
High level of abstraction. We have found that using ATL to describe our model
querying algorithm offers a high level of abstraction, especially when compared
to hierarchy slicing algorithms like the one presented in [10], due to its declarative
constructions (i.e.; the matching of model elements).
Expressive code. The code written to implement the algorithm is much more
compact and expressive than if written in a general purpose programming lan-
guage, like C++; this is a direct consequence of ATL being a DSL for model
transformation.
Code modularization and change management. Rule definition provides a
strong mechanism for code modularization (i.e.; a rule encodes by itself all the
functionality) and change management (e.g.; adding new behavior to the algo-
rithm is as simple as writing new rules).
31

Performance. The preliminary results we obtained encourage us to think of
ATL as applicable to industrial-size models.
Tool support. ATL comes with a virtual machine, an editor with syntax high-
lighting and code completion for metamodel elements, a debugger. Although suf-
ficiently mature to support development, these tools have missing features that
would increase their efficiency (e.g.; adding a breakpoint has to be done from the
outline view, there is no code completion for rules, attributes, helpers defined
in the same module, no code completion for data types). Also, there are minor
bugs (e.g.; the operation excludesAll on a collection does not work in the ATL
version8 we used - we had to find a workaround - see helper ldSags).
Functional programming style. The functional programming style (e.g.; used
to specify the conditions for matching) may be difficult for many programmers to
use. Moreover, this programming style produces complex and long expressions,
hard to read and understand. Having the documentation of an element appear
as a tool tip when hovering over it may be highly useful.
Factorization limits. When comparing the rules moveAssocDownHierarchy
and markAsSag, one observes that the from parts are very similar. We have
actually tried to write only one rule, but did not succeed. However, having
different rules contributes to the modularity and readability of the code, as each
addresses different functionality.
6 Conclusion and Future Work
In this work we were interested in defining a Domain Definition Metamodel
(DDMM) for Telecommunications service definition by model querying and trans-
forming large Network Abstraction Layers (NALs) expressed as UML models.
We defined the querying and transformation rules in ATL, finding this approach
well suited. In the future, we intend to measure the performance of our model
transformation rules on industrial-scale NALs (tens of thousands of classes). We
also plan to evaluate the DDMM against service designers and use their input
to further enlarge and refine it.
References
1. Fahy, C., Davy, S., Boudjemil, Z., van der Meer, S., Loyola, J., Serrat, J., Strass-
ner, J., Berl, A., de Meer, H., Macedo, D.: Towards an Information Model That
Supports Service-Aware, Self-managing Virtual Resources. In: Proceedings of the
3rd IEEE international workshop on Modelling Autonomic Communications En-
vironments, Springer (2008) 102–107
2. Barrett, K., Davy, S., Strassner, J., Jennings, B., van der Meer, S., Donnelly, W.:
A Model Based Approach for Policy Tool Generation and Policy Analysis. In:
Proceedings of the IEEE Global Information Infrastructure Symposium. (2007)
99–105
8 org.eclipse.m2m.atl.engine.vm 2.0.0
32

2specification of chains of transformations, i.e., it remains at quite a low level.
Furthermore, the analysis capabilities of the Ant task specifications are limited.
In this paper we present Wires*, a Domain Specific Language that enables the
high-level orchestration of model transformations. It provides a visual notation
for defining chains of model transformation in a modular and compositional
manner, and it is supported by a graphical framework and an execution engine
that loads the appropriate models and execute the transformations along the
pre-defined path.
The structure of this document is as follows. After this introduction, Section 2
presents the Wires* language. Then, Section 3 describes the execution engine
that interprets Wires* models and executes the model transformations. Finally,
Section 4 compares our work with other related proposals, and Section 5 draws
some conclusions and outlines some future research activities.
2 The Wires* Language
Wires* is a graphical executable language for orchestrating ATL transforma-
tions. Fig. 2 shows the metamodel of the language. Basically, Wires* assumes
a data-flow process, in which a set of input models (conforming to their corre-
sponding metamodels) are processed by a chain of ATL transformations until
a set of output models is produced. The chain is composed of transformations,
which act as processing nodes. Parameters represent the consumed and produced
data by transformations. Transformations are wired together by directed con-
nectors (called Dataflows or, simply, Wires) that indicate how the outputs of the
transformations are linked to the inputs of the next ones. Fig. 1 shows a simple
example, where an input model m1 is transformed by two transformations in a
row to produce an output model m3.
Fig. 1. A simple chain of 2 model transformations.
Although our notation may resemble at first simple UML 2 activities (trans-
formations are represented by activity nodes, models are represented by object
nodes, and wires by object flows), there is a significant difference in the seman-
tics. Basically, Wires* is a data-flow oriented language, whilst UML 2 activities
can be either data- or process-flow oriented, or both.
The following paragraphs describe the main concepts of the language with
more detail.
Models. In our approach we consider that models and transformations are
course-grained building blocks of the MDE process. Models are typed by the
35

4initial metamodel (ModelType) they conform to [3]. Models without incoming
Dataflows represent the input models of the process (i.e., the models that are
initially loaded), while models with incoming Dataflows represent output models
(i.e., models that are saved). Primitive data types (BasicDataType) are also
supported.
Transformations. We contemplate the three different kinds of units defined by
ATL: modules, libraries and queries. ATL modules and queries are specified by
instances of AtomicModelTransformation and Query metaclasses, respectively.
They are separated from their corresponding specifications (AtomicModelTrans-
formationType and QueryType, respectively), on which we specify the data file
where they are stored (the path attribute), their input and output formal param-
eters, as well as the auxiliary Libraries they make use of. AtomicModelTrans-
formations may have multiple input and multiple output models. Queries have
one single output, which is a primitive type value; one common use of a Query
is the generation of a textual output (encoded in a string value), which can be
stored in a text file (using BasicData instances).
In addition to Atomic transformations, which represent basic ATL trans-
formations, we also allow the definition of Composite transformations, which
represent chains of transformations which can be later used as a single (atomic)
transformation, i.e., as building blocks to specify further transformations. Fig. 3
shows an example of the specification of a composite model transformation, CT1,
made of t1 followed by t2.
Fig. 3. The specification of a Composite transformation
We have also identified two special kinds of atomic transformations: Iden-
tity and Generic. Identity transformations are model transformations that do
not alter the data which flow through them (they are very useful for defining
conditional compositions of transformations, as we shall later see). Generic trans-
formation are those used to load and execute ATL transformations produced by
high-order transformations. They have a special input parameter (typeParam)
that should conform to the ATL metamodel.
Fig. 4 depicts an example of the specification of a Generic transformation.
It shows a high-order transformation HOT that produces a transformation out-
Transf, which is passed as input to the generic transformation gt. Then, gt builds
the ATL code corresponding to the model outTransf, compiles it and executes it
37

8Fig. 8. A loop with Wires*
Fig. 9. A chain of transformations with persistent storage of intermediate result.
those transformations which are enabled (i.e., transformations with every input
models loaded and with their branch enabled if they are connected to a decision
node) and whose input models are already loaded. Once these transformations
are identified, they are loaded and executed, producing the corresponding output
models. The process continues until no enabled transformation is left unexecuted.
The pseudocode shown in Fig. 10 describes the structure and basic behavior
of the algorithm. To illustrate this behavior, let us describe the execution of
the chain depicted in Fig. 6. Firstly the execution engine identifies the models
without incoming data flows (input models), in this case model m1. The algo-
rithm determines its outgoing elements, which are the id identity transformation,
the query q and the cluster transformation. Although the execution order is not
pre-determined, let us suppose a left-to-right order. Then, the algorithm checks
whether id is enabled, but it is not because the decision node has not activated
any branch yet. Secondly, the engine tries to execute the query q, which is pos-
sible because its input model is loaded and it is enabled (not connected to any
41

10
Fig. 11. Fragment of the chained transformations of the VIASCO process
into components; cluster them to build the software architecture; measure the
components and their connectors; and finally visualize the system. This approach
provided a very clean and modular way to design, architect and develop the tool,
and is shown in Fig. 11.
There are already some approaches for chaining model transformations, some
of them graphical and very powerful such as UniTI [6], other textual such as
MCC [7], and others that use UML activity diagrams for specifying the flow of
control (e.g. [8]). In general, they allow model transformations written in differ-
ent languages to be composed to form a chained process that can be executed.
The Sensoria Development Environment (SDE) [9, 10] provides a very powerful
graphical notation and environment for the orchestration of software tools (and
in particular of model transformations) using a MDE approach. However, when
we tried to use these tools with ATL in our project we ended up using none of
them, but a set of Ant tasks [11]. Basically, we wanted a quick and very simple
way to chain several ATL transformations in a row. In this sense, ATLFLow [12]
is a graphical editor for transformation processes with ATL. It describes the
structure of a transformation flow, and it has the ability to execute both trans-
formations and generators. However, it does not provide support for conditional
branches nor for composite transformations.
43

12
the output of a transformation and the input of another, in such a way that
type safety is guaranteed. Thus, we are currently adding a metamodel subtyping
algorithm [3, 17] to our execution engine.
Secondly, we also want to connect our tool with other kinds of model trans-
formations, such as model injectors and extractors (defined using, e.g., TCS).
Finally, as future extensions we’d also like to explore the possibility of inte-
grating and executing model transformations defined in other languages, as well
as incorporating new ATL features as they are released.
Acknowledgements. This work has been supported by Spanish Research Projects
PET2006-0682-00, P07-TIC-03184 and TIN2008-03107.
References
1. Allilaire, F., Be´zivin, J., Brunelie`re, H., Jouault, F.: Global Model Management in
Eclipse GMT/AM3. In: Proc. of the Eclipse Technology eXchange (eTX) workshop
at ECOOP 2006, Nantes, France (2006) http://www.sciences.univ-nantes.fr/
lina/atl/AMMAROOT/AM3/.
2. Be´zivin, J., Jouault, F., Rosenthal, P., Valduriez, P.: Modeling in the large and
modeling in the small. In Aßmann, U., Aksit, M., Rensink, A., eds.: Model Driven
Architecture, European MDA Workshops: Foundations and Applications (MDA-
FA 2003/2004). Volume 3599 of LNCS., Springer (2005) 33–46
3. Romero, J.R., Rivera, J.E., Dura´n, F., Vallecillo, A.: Formal and tool support for
model driven engineering with Maude. Journal of Object Technology 6(9) (2007)
187–207
4. Rivera, J.E., Guerra, E., de Lara, J., Vallecillo, A.: Analyzing rule-based behavioral
semantics of visual modeling languages with Maude. In: Proc. of the first Interna-
tional Conference on Software Language Engineering (SLE’08). LNCS, Toulouse,
France, Springer (2008)
5. Rivera, J.E., Vicente-Chicote, C., Vallecillo, A.: Extending visual modeling lan-
guages with timed behavioral specifications. In: Proc. of IDEAS 2009, Medell´ın,
Colombia (2009)
6. Vanhooff, B., Ayed, D., Baelen, S.V., Joosen, W., Berbers, Y.: UniTI: A Unified
Transformation Infrastructure. In: Proc. of MoDELS 2007. Number 4735 in LNCS,
Springer-Verlag (2007) 31–45
7. Kleppe, A.: MCC: A Model Transformation Environment. In: Proc. of ECMDA-FA
2006. Number 4066 in LNCS, Springer-Verlag (2006) 173–187
8. Oldevik, J.: Transformation composition modelling framework. In: Proc. of DAIS
2005. Number 3543 in LNCS, Springer-Verlag (2005) 108–114
9. Foster, H., Mayer, P.: Leveraging Integrated Tools for Model-Based Analysis of
Service Compositions. In: Proceedings of the 2008 Third International Conference
on Internet and Web Applications and Services (ICIW 2008), IEEE Computer
Society (2008) 72–77
10. Mayer, P., Ra´th, I., Horva´th, A.: Report on the Sensoria Development Environment
(second version). Project deliverable D7.4.c, SENSORIA EU-IST Project (2008)
http://www.pst.ifi.lmu.de/projekte/Sensoria/del_36/D7.4.c.pdf.
11. ANT: The Apache Ant Project (2008) http://ant.apache.org/.
12. Zeidler, U.: (ATLFlow) http://opensource.urszeidler.de/ATLflow/.
45

13
13. OMG: MOF QVT Final Adopted Specification. Object Management Group. (2005)
OMG doc. ptc/05-11-01.
14. Kurtev, I., van den Berg, K., Jouault, F.: Evaluation of rule-based modularization
in model transformation languages illustrated with ATL. In: Proc. of the Model
Tranformation track at ACM SAC 2006 (MT 2006), ACM Press (2006) 1202–1209
15. Wagelaar, D.: Composition techniques for rule-based model transformation lan-
guages. In: Proc. of ICMT 2008. Number 5063 in LNCS, Springer-Verlag (2008)
152–167
16. Sa´nchez-Cuadrado, J., Garc´ıa-Molina, J.: Approaches for model transformation
reuse: Factorization and composition. In: Proc. of ICMT 2008. Number 5063 in
LNCS, Springer-Verlag (2008) 168–182
17. Steel, J., Je´ze´quel, J.M.: On model typing. Software and Systems Modeling 6(4)
(2007) 401–413
46

Typing ATL Models in Global Model
Management
Andre´s Vignaga and Mar´ıa Cecilia Bastarrica
MaTE, Department of Computer Science, Universidad de Chile
{avignaga,cecilia}@dcc.uchile.cl
Abstract. A typing approach for models, and in particular for model
transformations, is required for preventing type errors during execution
in a Global Model Management (GMM) environment. Based on our pre-
vious proposal, in this work we specifically address the typing of ATL
models, which are ATL modules and ATL libraries. We discuss function
types for ATL modules, and how they are affected by a specific property
exhibited by ATL higher-order transformations. We also propose a new
type for ATL libraries and discuss additional checks enabled by it. We
organize these types in a hierarchy of types for GMM.
1 Introduction
Model transformations are widely recognized as key assets in Model Driven En-
gineering (MDE) and the AtlanMod Transformation Language (ATL) is a widely
used language for defining model transformations. Although the development of
a single transformation can be properly addressed using ATL tools, managing
a large amount of transformations, along with all their associated assets, could
be impractical. Proposals like Global Model Management (GMM) [6], based on
the notion of megamodel [4], tackle this issue. In practical terms, a tool imple-
menting GMM enables the execution and composition of model transformations
among others. AM3 is one of those tools, which provides specific support for
ATL transformations execution via the GMM4ATL extension. In the future, ex-
ecution support for other model transformation languages (e.g., QVT) may be
integrated into AM3 by developing other appropriate extensions. The language
supported by the GMM4CT extension is not a general purpose model trans-
formation language, but rather it is a language for defining transformations as
compositions of other transformations. When any form of execution is taken into
consideration, the notion of execution error is also present. A form of execution
error is a type error. A definition of type error depends on a specific language,
but always includes the application of a function on arguments for which it was
not defined, and the attempted application of a non-function [16]. This kind of
errors may be prevented by typing. A type system addressing a set of forbidden
errors [7] may be used for determining if a program is well typed or not. A
program which is well typed with respect a consistent type system exhibits good
behavior, that is, it does not produce forbidden errors upon execution. Our main
47

2concern is to ensure good behavior in GMM, and typing elements within GMM
is therefore a means for achieving it.
Understanding model transformations as functions, transformation applica-
tion and composition may cause the aforementioned kinds of type errors. Thus,
an appropriate typing approach for model transformations is core to our goal.
The typing approach currently defined in GMM does not ensure good behavior
in some specific situations, especially when higher-order transformations (HOT)
are involved. This issue was addressed in [15]. However some concerns which
are required for its practical realization have not been addressed yet. For exam-
ple, the potential coexistence of heterogeneous atomic transformations was not
taken into account and a single language approach was assumed for that kind of
transformations. Additionally, specificities of ATL transformations, such as the
separation of modules from libraries, were also ignored. GMM4ATL is currently
the only extension for managing atomic transformations within GMM. For this
reason in this paper we address in detail the typing of ATL models: ATL mod-
ules and ATL libraries. ATL queries are another kind of ATL models but they
are not supported by GMM, and they fall out of the scope of this work.
Our proposal enables a more powerful typing approach for ATL models
within GMM than the one currently implemented. Its realization then con-
tributes to an enhanced environment for using ATL transformations in practice.
Moreover, our results may be used as a basis, or may be even extended, for
defining equivalent typing approaches for future GMM extensions.
The remainder of this paper is structured as follows. Section 2 reviews typing
approaches for model transformations and their shortcomings. The typing of
ATL modules is discussed in Sect. 3. In Sect. 4 ATL libraries are addressed and
an improvement to the GMM4ATL metamodel is proposed. Our conclusions and
future directions are discussed in Sect. 5.
2 Background
In this section we review the basic concepts of Global Model Management which
enable a proper description of the problem addressed in this work. This includes
an overview of GMM, a description of its general typing approach, a detail of
how ATL models are typed, and an example that illustrates its shortcomings.
2.1 An Overview of GMM
A Global Model Management approach is based on several general concepts
corresponding to a generic conceptual MDE framework [5], and also on the
concept of a megamodel [4] as a building block for modeling in the large [6]. A
megamodel can represent different artifacts (i.e., models) involved in a real world
system or process, and their relationships by specifying associated metadata. The
type of an artifact, the identifier of a given artifact and its location, etc., are
examples of such registered metadata.
48

4transformation definition. As a consequence, the ATLTransformation relation-
ship may be regarded as a proper function type for an ATLModule, but only
when non-transformation terminal models are involved as the source or target
in that module.
2.3 A Concrete Example
For illustrating this issue we consider the case of the ATL transformation Trac-
erAdder reported in [10]. This transformation receives a transformation t and
returns an updated version t’ of it. The update consists in the addition of target
patterns and actions to every rule of t. With such additions, the t’ transforma-
tion still produces the same results as t, but also produces a tracing model. Such
a model provides tracing information about source and target elements of t’. We
recall that the header of an ATLModule expresses the same type information
as the ATLTransformation associated to that module. The ATL header of Trac-
erAdder as taken from its original version is as follows (the has-type relation
denoted by ‘:’ is :GMM):
create OUT : ATL refining IN : ATL;
TraceAdder is a HOT and is thus in the hypotheses of the case we described
before. This header says “TraceAdder receives any ATL transformation and
produces an ATL transformation.” In particular, there is no restriction on the
sources and targets of IN, which is appropriate. However, there is also no re-
striction on the sources and targets of OUT. Even though TracerAdder is typed
as a function, IN and OUT are not, and thus this header is a one-level function
type. This causes a loss of information which may lead to execution errors. For
illustrating this we use the sample transformation Src2Dst introduced in the
presentation of TracerAdder. The header of Src2Dst is:
create OUT : Dst from IN : Src;
The result of applying TracerAdder to transformation Src2Dst is transfor-
mation Src2DstPlusTrace. The header of such a transformation is therefore:
create OUT : Dst, trace : Trace from IN : Src;
It can be seen that there exists a relationship between both headers. In par-
ticular, the header of Src2DstPlusTrace is the same as that of Src2Dst with the
addition of target model trace. Such a relationship holds for any pair of source
and target transformations of TracerAdder. However, it cannot be captured in
the header of TracerAdder. If that relationship could be expressed, then it could
be possible to statically infer the function type of the target transformation t’
as soon as the function type of the source transformation t is known. With the
currently available information, the type of source and target models of t’ are
unknown, even after it was generated. As a consequence, further executions of
50

6name
isParameter
source
target
{ordered}
1
1
2..*
Fig. 1. Partial hierarchy of GMM types
«atl module»
«terminal model»
IN
OUT«terminal model»
IN«source»
«transformation type»
«metamodel type» «metamodel type»
OUT«target»
«atl module»
«terminal model»
IN
OUT«terminal model»
IN«source»
«transformation type»
«metamodel type» «metamodel type»
OUT«target»
(a) (b)
Fig. 2. Application of GMM types to the Class2Relational transformation. Types are
shown in (a). Some typed entities involved in a concrete application are shown in (b).
transformation having more than one argument and producing more than one
result.
For illustrating the use of such types, we show in Fig. 2 the very simple case
of the Class2Relational transformation [2]. In (a) we show all involved types:
metamodels Class and Relational are the source and target types of transforma-
tion type Class→Relational respectively. In (b) we show a concrete application of
Class2Relational, which is an ATL module, on model sampleClass for producing
model sampleRel. Note that we used :GMM for typing these terminal models,
whereas we used :Trans for typing Class2Relational.
Transformation models are naturally expressed in a concrete language, we
therefore label Class2Relational as an atl module. However we found more ap-
propriate to keep transformation types technology independent. This enables
multiple transformations definitions, which correspond to the same conceptual
transformation, in potentially different languages to be typed by the same type.
For example, an implementation of Class2Relational in QVT could be typed by
Class→Relational as well.
52

7IN
trace
«gmm type» «gmm type»
«target»
«source» «target»
«source» «target»
«atl module type»
«atl module type»
OUT
«metamodel type»
«atl module type»
«source» «target»
«bind»<A Src,B Dst>
«atl module»
«atl module»
IN
OUT
«atl module»
(a) (b)
Fig. 3. Application of GMM types to the TracerAdder transformation. Types are shown
in (a). Some typed entities involved in a concrete application are shown in (b).
This scheme enables the occurrence of transformation types within trans-
formation types, unlike the current typing approach. This could suggest that
it suffices for properly handling cases such as that of TracerAdder introduced
before. Next, we will discuss the case of higher-order transformations, and we
show that additional considerations are required, and a compromise concerning
the decision just discussed above must be made.
3.2 Higher Order Transformations
As model transformations can be regarded as functions, it is natural to think
of higher-order transformations as higher-order functions. The typing approach
described above is in fact capable of handling cases as that of TracerAdder.
In Fig. 3 we show a similar but more advanced application of types than the
one in Fig. 2. In (a) all involved types are represented. At the top we show
a (transformation) type for the TracerAdder module. Both of its source and
target types are transformation types. The source represents the type of an
arbitrary transformation, which is parameterized at its source and target types.
Such types are parameters (denoted by a dashed box) and could be any kind of
GMM type. Therefore the type of such an arbitrary transformation could be read
as ∀A,B:GMMType.A→B. Then the type of the result is another transformation
type. First, types A and B are the same as those used in the source transformation
type. In this way we capture that relation between the source and target types of
TracerAdder we discussed in the previous section. Second, the target type of the
target transformation is actually a product B×Trace, where B is a parametric
type and Trace is a concrete metamodel. In Fig 3 we do not explicitly represent
such a product, rather, we include an association stereotyped as target for each
component of the product. In (b) we show the application of TracerAdder to
the sample Src2Dst transformation for producing Src2DstPlusTrace. For inferring
the type of the latter, type parameters need to be bound. Such a binding is
expressed on the link between Src2Dst and TracerAdder. Such an instantiation
produce Src2Dst’s type from the source type of TracerAdder, meaning that the
53

8name
isParameter
source
target
context
{ordered}
1
1
1..*
2..*
Fig. 4. Updated partial hierarchy of GMM types with specific transformation types
and library types
application is correct. But also, that instantiation produces from the target type
of TracerAdder the right type for Src2DstPlusTrace.
Higher-order transformations and higher-order functions exhibit some funda-
mental differences which compels us to further refine our typing proposal. First,
in functional languages, functions are assumed to be implemented in the same
language. This is not the case with transformations in GMM. Second, a higher-
order function receives a function typically for applying it, or in some cases for
passing it as a parameter to another function or even for returning it as a result.
At least in ATL, a higher-order transformation receives another transformation
just for reading and processing its definition. Consider the following implemen-
tation in Haskell of the well-known map higher-order function:
map f [] = []
map f (x:xs) = f x : map f xs
In the second line, argument f is used for applying it to x and also for passing it
as a parameter in the recursive call. In a higher-order ATL transformation, the
definition of a source transformation is used for producing the result. For exam-
ple, TracerAdder reads the definition of Src2Dst and produces the result based
on the elements present in that definition. As a consequence it is not the case
that TracerAdder accepts an arbitrary transformation. Instead, TracerAdder ac-
cepts an arbitrary ATL transformation, because it relies on the ATL metamodel
for processing the input. Note that this particular piece of type information was
already provided when transformations were typed based on :GMM, and it was
lost in the transition to the :Trans-based approach.
In concrete terms, a transformation type needs to indicate a transformation
metamodel name. The meaning of this is that transformation models of that type
must conform to the abstract syntax specified by the metamodel. We realize this
54

9idea by annotating transformation types with the name of a transformation lan-
guage. For example, the type of the Class2Relational transformation of Fig. 2,
which was defined as an ATL module, should be now ClassATL→Relational. In Fig. 4
we show an updated version of the type hierarchy for GMM. TransformationType
is now abstract and we added the specific type ATLModuleType which corre-
sponds to
ATL
→ . New transformation types for future languages should be siblings
of this type. Note that we already used this new type in part (a) of Fig. 3.
Higher-order transformations will depend on the abstract syntax of the lan-
guages used for defining their inputs as long as they are intended to process
the definitions of such inputs. In turn, the ability of supporting transformations
expressed in different languages is in the rationale of GMM. However, if ev-
ery transformation language supported by GMM could compile to a common
base language, as the .NET Framework does with the Common Intermediate
Language (CIL) [9], then HOTs still would be in position of processing transfor-
mation definitions, but the dependency to different languages could be relaxed.
Therefore transformations would be actually defined in a single language, thus
language annotations in transformation types could be removed, but transfor-
mations could still be presented to end users in different concrete syntaxes. Such
a base language could be the ATL virtual machine byte-code. In that case,
transformation models would be replaced by ASM [3] models. Besides this, this
approach poses two severe restrictions. First, every language supported by GMM
should have an ASM compiler and decompiler. ATL naturally has such tools,
and for example such a compiler for QVT is available in the QVT to ATL Virtual
Machine Compiler transformation [2]. However, other languages may present ir-
reconcilable incompatibilities with ASM. Second, HOTs must operate on ASM
transformations, thus relying on ASM abstract syntax. This could be awkward
for most transformation developers.
In the next section we address the typing of other ATL models present in
GMM: ATL libraries. We propose a new type for such models and discuss some
applications of it. In particular, stronger checks involving libraries and modules
are enabled.
4 Typing ATL Libraries
In this section we focus on ATL libraries. First, we discuss the definition of the
concept of a library within GMM and suggest an improvement to the GMM4ATL
extension. Then, we propose a new type for ATL libraries. Finally, we discuss
possible connections between the type of ATL modules and the proposed type
for ATL libraries, which leads to stronger type checks.
4.1 ATL Libraries in GMM
ATL libraries are models defining a number of ATL helpers, which may be
imported from either other ATL modules or other ATL libraries. Helpers defined
within an ATL library may be called from any ATL model importing that library.
55

15
mation models. We also incorporated the new type for libraries ATLLibraryType,
which enable stronger checks when a library model is involved in a transforma-
tion. Our proposal improves our more general typing approach for GMM as ATL
models were addressed in more detail. This may be used to enhance GMM-based
environments, such as AM3 [1], as some type errors may be prevented by appro-
priately typing transformations and by checking their applications, either when
they are stand-alone or when they occur within the definition and execution of
composite transformations. Our GMM type hierarchy may be used as a basis for
typing approaches in future GMM extensions as well.
The typing of ATL models has been addressed in the definition of the ATL
language when the headers of ATL transformations were defined. This defini-
tion influenced the typing approach currently supported by GMM. To the best
of our knowledge, a detailed discussion on the typing of ATL models includ-
ing HOTs and libraries has not been presented before. The formalization of the
MOF layered architecture using Constructive Type Theory in [12] focuses on
typing terminal models in general and MOF-based metamodels specifically. In
particular, model transformations as MDE-based assets are not addressed, and
function types for their typing are only suggested. Model typing is also addressed
in [13], where model transformations are typed as well. There, model transfor-
mations are in-place procedures, rather than functions, defined in a proprietary
research-oriented model transformation language. In particular, transformations
are not treated as models, and HOTs are not supported.
In what follows, we plan to integrate our results to the AM3 tool for re-
alizing the benefits of our proposal in a practical environment. Other future
work include providing a similar treatment to the typing of other specific mod-
els managed by GMM, such as weaving models and text-to-model/model-to-text
transformations. ATL models may be related among them, and in this paper we
discussed one such static relationship from a typing perspective. Another possi-
ble relationship is “superimposition,” which enables a module to incorporate or
override either rules or helpers from another module. Such a relationship is pro-
cessed at module load-time and is therefore dynamic. Currently AM3 does not
support superimposition and we plan to address this issue in the future. How-
ever, from a typing point of view, it suffices that two modules have the same type
for one being safely superimposed by the other. Since the language for composite
transformations supported by the GMM4CT extension involves the execution of
subtransformations, the multi-language aspect is not an issue like in the case of
HOTs. This should to be further taken into account when typing such compos-
ite transformations by appropriately using the TransformationType type shown
in Fig. 4. Our approach would benefit from metamodel subtyping as supported
in [13] as it enables model substitutability in transformation applications. This
is related to subtyping transformation types, which in turn enables the potential
application of different transformations to the same set of models.
References
1. AM3 Project. Internet: http://www.eclipse.org/gmt/am3/, 2009.
61

16
2. ATL Transformations Zoo. Internet: http://www.eclipse.org/m2m/atl/
atlTransformations/, 2009.
3. ATLAS group. Specification of the ATL Virtual Machine. Internet:
http://www.eclipse.org/m2m/atl/doc/, 2005.
4. M. Barbero, F. Jouault, and J. Be´zivin. Model Driven Management of Complex
Systems: Implementing the Macroscope’s Vision. In 15th ECBS’08, pages 277–286.
IEEE, 2008.
5. J. Be´zivin and F. Jouault. KM3: a DSL for Metamodel Specification. In 8th IFIP,
pages 171–185, 2006.
6. J. Be´zivin, F. Jouault, P. Rosenthal, and P. Valduriez. Modeling in the Large and
Modeling in the Small. In U. Aßmann, M. Aksit, and A. Rensink, editors, MDAFA,
volume 3599 of Lecture Notes in Computer Science, pages 33–46. Springer, 2004.
7. L. Cardelli. Type Systems. In A. B. Tucker, editor, The Computer Science and
Engineering Handbook, pages 2208–2236. CRC Press, 1997.
8. K. Czarnecki and S. Helsen. Feature-based Survey of Model Transformation Ap-
proaches. IBM Systems Journal, 45(3):621–645, 2006.
9. ECMA. ECMA-335: Common Language Infrastructure (CLI). ECMA (European
Association for Standardizing Information and Communication Systems), fourth
edition, June 2006.
10. F. Jouault. Loosely Coupled Traceability for ATL. In Proceedings of the Euro-
pean Conference on Model Driven Architecture (ECMDA) workshop on traceability,
pages 29–37, Nuremberg, Germany, 2005.
11. ModelPlex Project. Deliverable D2.1.b: “Model Management Supporting Tool”.
Internet: https://www.modelplex.org//index.php?option=com remository&
Itemid=0&func=startdown&id=183, March 2009.
12. I. Poernomo. A Type Theoretic Framework for Formal Metamodelling. In R. H.
Reussner, J. A. Stafford, and C. A. Szyperski, editors, Architecting Systems with
Trustworthy Components, volume 3938 of Lecture Notes in Computer Science,
pages 262–298. Springer, 2006.
13. J. Steel and J.-M. Je´ze´quel. On Model Typing. Software and System Modeling,
6(4):401–413, 2007.
14. A. Vignaga. Measuring ATL Transformations. Technical Report TR/DCC-2009-7,
Computer Science Department, Universidad de Chile, 2009.
15. A. Vignaga, F. Jouault, M. C. Bastarrica, and H. Brunelie`re. Typing in Model
Management. In R. Paige, editor, ICMT2009, to appear.
16. A. K. Wright and M. Felleisen. A Syntactic Approach to Type Soundness. Inf.
Comput., 115(1):38–94, 1994.
62

White-Box Coverage Criteria for Model
Transformations
Jacqueline A. McQuillan and James F. Power
Department of Computer Science,
National University of Ireland, Maynooth,
Co. Kildare, Ireland
{jpower@cs.nuim.ie}
http://www.cs.nuim.ie/research/pop/
Abstract. Model transformations are core to MDE, and one of the key
aspects for all model transformations is that they are validated. In this
paper we develop an approach to testing model transformations based
on white-box coverage measures of the transformations. To demonstrate
the use of this approach we apply it to some examples from the ATL
metamodel zoo.
Keywords ATL, model transformations, software testing, coverage criteria,
metamodels.
1 Introduction
Modelling is concerned with the construction and maintenance of models, but
also the transformation from one model to another in the context of Model
Driven Engineering (MDE). Model transformations are core to MDE and, sim-
ilar to conventional software, it is vital to validate the transformations and en-
sure they are correct. One possible validation method is to systematically test
the transformation. While much research has been conducted into transforma-
tion languages and tool support for conducting transformations, relatively little
attention has focused on testing the model transformations.
In this paper we address the problem of testing model transformations by
examining white-box coverage measures for model transformations. We report
on some initial experiments of applying this approach to some transformations
from the ATL transformation zoo.
The remainder of this paper is organised as follows. Section 2 outlines some of
the background information related to testing model transformations. In Section
3 we consider what kind of white-box coverage measures can be derived from ATL
transformations. In Sections 4 and 5 we illustrate the use of our test criteria using
two model transformation. Finally, Section 6 concludes the paper and discusses
future work.
63

4.2 Discussion
Even this simple example shows some of the difficulties involved in identify-
ing the effective metamodel for a transformation. Since the code for isFemale
could be substituted into the rule definitions, it should clearly be considered
relevant to determining the effective metamodel. However, the defined attribute
familyName is also relevant to the discussion, since it is defined entirely over
the input metamodel, and thus a test suite would need to ensure that all of the
possible permutations are exercised. Indeed, in this example there is very little
of the code that is not relevant to fully defining the effective metamodel.
Even considering decision coverage, as above, does not quite give a full picture
of metamodel coverage. For example, the coverage data for isFemale is the
amalgamated coverage for each call to the function. In theory, a fuller picture
would be given by considering the context of the call, so that we could distinguish
between isFemale as used by Member2Male and as used by Member2Female. Only
the example shown in Figure 2(d) exercises all these options, but this is not shown
in the context-independent data of Table 2. There is an obvious potential for
combinatorial explosion here, and further research would be required to see if
adding context was justified in terms of the improvement in test suite analysis.
5 A larger study
In this section we apply the coverage measures to a larger example, the UML2
to Measure transformation from the ATL Transformations zoo [15]. This trans-
formation calculates a set of metrics for UML class diagrams. As such, it has a
well-known source metamodel, so plenty of test cases are available. It also has
a computationally-intensive back-end that calculates 51 metrics over the input
UML class diagram. It thus represents an extreme example of a transformation
where the exact effective metamodel is not easily deducible.
The UML2 to Measure is composed of four modules: one main UML22Measure
module, and three modules that calculate metrics called MOOD4UML2, EMOOSE4UML2
and QMOOD4UML2. In what follows, we abbreviate these as U2M, MOOD,
EMOOSE and QMOOD respectively.
5.1 A test suite of UML class diagrams
The test cases used in our study were taken from the Eclipse UML2 Tools project
[16]. This project includes, among other examples, 19 UML class diagrams from
chapter 7 of the UML Superstructure Specification. The 19 class diagrams are
described briefly in Table 3, mainly to provide reference to the original source.
While there was no coverage data or analysis provided with these models, they
were selected as they presumably covered a wide range of features in class dia-
grams.
The relevant coverage measures were calculated for each of the 19 test cases
individually, and then calculated for the test suite as a whole.
870

Test Case Description used in UML2 Tools project
7.19 Graphic notation indicating exactly one association end owned by the
association
7.20 Combining line path graphics
7.21 Binary and ternary associations
7.22 Association ends with various adornments
7.23 Examples of navigable ends
7.24 Example of attribute notation for navigable end owned by an end
class
7.25 Derived supersets (union)
7.26 Composite aggregation is depicted as a black diamond
7.27a An AssociationClass is depicted by an association symbol (a line) and
a class symbol (a box)
7.27b Association Class
7.28 Class notation - details suppressed, analysis-level details,
implementation-level details
7.30 Examples of attributes
7.32 Comment notation
7.33 Constraint attached to an attribute
7.34 {xor} constraint
7.39 Example of element import
7.40 Example of element import with aliasing
7.48 Multiple ways of dividing subtypes (generalization sets) and con-
straint examples
7.54 Instance specifications representing two objects connected by a link
Table 3. A summary of the “Chapter 7” class diagrams from the UML2 Tools project
(release 0.8.1 (2008/09/23) [16]. In future tables we refer to these models by number
only; this table can be used to refer back to the models in the UML2 distribution.
5.2 Decision coverage results
Since there are 75 if instructions, this makes a total of 150 possible decisions,
and over half of these (88) in the U2M module. The results from the coverage
analysis are summarised in Table 4 on a per-model basis. This table has one
row for each of the UML models described previously in Table 3. The data in
each row represent the fraction of decisions covered for each module in the ATL
transformation, summed over all functions in that module.
For example, the value “28/88” in the first column of the first data row of
Table 4 measures the decision coverage for the U2M ATL module when run with
class diagram #19 as input. There were 44 if instructions in the module, so the
total possible decision coverage would have been 88. In this case, only 28 of the
possible true/false decisions were taken.
As can be seen from the data in Table 4, the test cases are relatively similar
in terms of their module-by-module coverage. This possibly reflects the nature
of the transformation itself: since all metrics are calculated for each test case,
the level of coverage is quite similar for each. It is notable that decision coverage
971

UML No. of if statements
Model Neither False True Both Total
19 26 24 18 7 75
20 26 24 18 7 75
21 27 24 17 7 75
22 23 25 15 12 75
23 26 24 18 7 75
24 26 24 18 7 75
25 29 17 19 10 75
26 33 16 21 5 75
27a 33 16 21 5 75
27b 25 23 21 6 75
28 21 30 10 14 75
30 14 33 8 20 75
32 35 13 24 3 75
33 30 21 20 4 75
34 32 15 24 4 75
39 34 11 24 6 75
40 28 17 22 8 75
48 28 16 22 9 75
54 27 21 23 4 75
Cum. Total 12 13 6 44 75
Table 5. A breakdown of the overall cumulative decision coverage data for all 19 UML
models. This table splits the decision instructions into four categories based on the
degree to which they were covered during the transformations.
that evaluated to both false and true. This gives a deeper insight as to the
overall cause of low coverage, since this could be due either to decisions not
being covered at all, or not being evaluated to all possibilities.
For example, the first data row of Table 5 shows the coverage details for
class diagram #19. From this we can see that 26 of the decisions in the ATL
transformation were never executed, 24 were executed and only ever evaluated
to false, 18 only ever evaluated to true, and just 7 were fully tested, being
evaluated to both false and true during the transformation. For comparison
with Table 4, we can calculate the total decision coverage for this test case as
24 + 18 + (7 ∗ 2) = 56, as shown in the final column of the first row of Table 4.
For individual test cases, relatively few of the if statements evaluate to both
true and false: only three test cases cause more than 10 of the 75 if statements
to be fully evaluated. Happily, the final row of Table 5 shows that in total 44 of
the 75 if statements are fully evaluated, and efforts to augment the test suite
need only concentrate on the remaining 31 statements.
1173

5.4 Comparison with instruction coverage
The ATL transformation contains 151 functions in total (excluding scaffolding
code), and these contain a total of 2988 ATL byte-code instructions. The to-
tal cumulative instruction coverage for all 19 test cases is 2626 instructions, or
88% of the total. Thus the instruction coverage runs well ahead of the decision
coverage figure of 71%.
Just 20 of the 151 functions were never called during any of the 19 transforma-
tion runs, and these account for a total of 201 instructions. Since 362 instructions
were not covered in total, this means that the remainder, 161/362, or 44% of the
uncovered instructions are directly attributable to decisions not taken. Indeed,
since the non-coverage of these instructions might have resulted in functions not
being called, the figure of 44% is actually a lower-bound on the influence of de-
cision coverage. This demonstrates that improving decision coverage can have a
significant impact on improving the coverage of the transformation as a whole.
In the previous subsection we noted that the deficiencies in decision coverage
resulted form the incomplete coverage of just 44 if statements. In fact, we can
make a further attempt to estimate the ease of localising the lack of coverage.
Of the 131 functions that were called at least once during the 19 transformation
runs, 104 of these have 100% decision coverage. In fact, of these, 73 contain no
decision instructions, and so the function call covers all decisions by default. This
means that locating the decisions not taken is localised to just 27 of the 151 func-
tions in the ATL transformation. This suggests that tracking down incomplete
decision coverage is at least feasible, even in a relatively large transformation.
6 Conclusion and Future Work
In this paper we have noted the dual nature of a model transformation: part
input-recognition, like a grammar, and part generation, like program code. Thus
it is possible to extend the notion of rule coverage from grammars to model
transformations, and use instruction and decision coverage to evaluate the re-
maining elements. We have developed tool support to measure decision coverage
for the transformation language ATL. Finally, we have shown how these criteria
were used in the process of testing a specific model transformation.
The work presented in this paper takes place in the overall context of de-
veloping a framework for calculating metrics from various kinds of models. Our
approach is based on designing a single metamodel, called the measurement
metamodel that describes the quantifiable elements used in software metrics [17,
12]. We are in the process of developing a set of model transformations from
other artifacts, such as UML class diagrams and Java programs, into this mea-
surement metamodel. Hence, in order to ensure the correctness of the resulting
metrics it is important that the model transformations faithfully represent the
source models in each case.
This paper is a first step in identifying suitable white-box coverage measures.
In future work we plan to validate the utility of these coverage measures primarily
1274

by examining their correlation with coverage of the effective metamodel. We
also intend to compare the fault-detection effectiveness of the coverage criteria
presented in this paper with other test adequacy criteria in the literature such
as that in [5, 2]. Using this information we plan to establish a full set of test
adequacy criteria for testing model transformations and use these criteria for
automating the generation of test cases for model transformation testing.
References
1. McQuillan, J.A., Power, J.F.: A survey of UML-based coverage criteria for soft-
ware testing. Technical Report NUIM-CS-TR-2005-08, Dept. of Computer Science,
National University of Ireland, Maynooth (September 2005)
2. Andrews, A., France, R., Ghosh, S., Craig, G.: Test adequacy criteria for UML
design models. Software Testing, Verification and Reliability 13 (2003) 95–127
3. Gogolla, M., Bohling, J., Richters, M.: Validating UML and OCL models in USE
by automatic snapshot generation. Journal on Software and System Modeling 4(4)
(2005) 386–398
4. Ehrig, K., Ku¨ster, J., Taentzer, G., Winkelmann, J.: Generating Instance Models
from Meta Models. In: 8th IFIP Intl. Conf. on Formal Methods for Open Object-
Based Distributed Systems. (June 2006) 156–170
5. Fleurey, F., Steel, J., Baudry, B.: Validation in model-driven engineering: Testing
model transformations. In: Workshop on Model Design and Validation. (2004)
6. Brottier, E., Fleurey, F., Steel, J., Baudry, B., Traon, Y.L.: Metamodel-based test
generation for model transformations: an algorithm and a tool. In: International
Symposium on Software Reliability Engineering, Raleigh, NC (November 2006)
85–94
7. Fleurey, F., Baudry, B., Muller, P., Traon, Y.L.: Qualifying input test data for
model transformations. Software and Systems Modeling (2009) (to appear)
8. La¨mmel, R.: Grammar testing. In: Fundamental Approaches to Software Engi-
neering, Genova, Italy, Springer Verlag (April 2-6 2001) 201–216
9. La¨mmel, R., Schulte, W.: Controllable combinatorial coverage in grammar-based
testing. In: 18th IFIP TC6/WG6.1 International Conference on Testing of Com-
municating Systems, New York, USA (May 2006) 19–38
10. Hennessy, M., Power, J.F.: Analysing the effectiveness of rule-coverage as a re-
duction criterion for test suites of grammar-based software. Empirical Software
Engineering 13(4) (2008) 343–368
11. Binder, R.: Testing Object Oriented Systems: Models, Patterns and Tools.
Addison-Wesley (October 1999)
12. McQuillan, J.A., Power, J.F.: A metamodel for the measurement of object-oriented
systems: An analysis using alloy. In: IEEE International Conference on Software
Testing Verification and Validation, Lillehammer, Norway (April 9-11 2008) 288–
297
13. Jouault, F., Allilaire, F.: The ATL virtual machine. Available on-line as http:
//www.eclipse.org/m2m/atl/doc/ATL_VMPresentation[v00.01].pdf (2006)
14. Allilaire, F., Jouault, F.: Presentation families to persons. http://www.eclipse.
org/m2m/atl/basicExamples_Patterns/ (February 2007)
15. Ve´pa, E.: ATL transformation example: UML2 to measure. http://www.eclipse.
org/m2m/atl/atlTransformations/
1375

16. The Eclipse Foundation: Eclipse modeling - model development tools: UML2 tools.
http://www.eclipse.org/modeling/mdt/ (2009)
17. McQuillan, J.A., Power, J.F.: On the application of software metrics to UML
models. In: Models in Software Engineering. Volume 4364 of Lecture Notes in
Computer Science., Springer (2007) 217–226
1476

– ASMTransientLink.getSourceElementsMap(): this method returns a map of
the source elements of the transient link. The key of the map is the name of
the source variable and the value is the source element.
– ASMTransientLink.getTargetElementsMap(): this method returns a map of
the target elements of the transient link. The key of the map is the name of
the target variable and the value is the target element.
With these added methods, the ATL user can access the implicit tracing
information using the ATL (hidden) helper attribute thisModule.links. For in-
stance, this richer access allows to the developer to get the target elements by
their type or to produce a tracing model. It is critical to only access this informa-
tion as a final step in the transformation, when all the elements are created and
assigned after all the rules have been matched and all (traced) model elements
are created. In practice, this means that the tracing information should not be
accessed in the from part of matched rules or in helper attributes without con-
text. To be safe, this access can be done in an endpoint rule, as was presented
in Listing 2. The purpose of the rules in Listing 2 is to generate a tracing model
as a final step of a transformation execution.
1 endpoint rule getTraceModel () {
2 to
3 trace : TRACE!TraceModel (
4 name <- thisModule.toString(),
5 traces <- thisModule.links.getLinks()->collect(e |
6 thisModule.getTraceLink(e))->flatten ()
7 )
8 }
9
10 rule getTraceLink(inSource : OclAny) {
11 to
12 trace : TRACE!TraceLink (
13 name <- inSource.getRule (). toString(),
14 sources <- inSource.getSourceElementsMap (). getKeys()->collect(e |
15 thisModule.getElement(e, inSource.getSourceElementsMap ().get(e))),
16 targets <- inSource.getTargetElementsMap (). getKeys()->collect(e |
17 thisModule.getElement(e, inSource.getTargetElementsMap ().get(e)))
18 )
19 do {
20 trace;
21 }
22 }
23
24 rule getElement(name : String , element : OclAny) {
25 to
26 outelement : TRACE!TracedElement (
27 name <- name
28 )
29 do {
30 outelement.refSetValue(’ref ’, element );
31 }
32 }
Listing 2. Tracing transformation rules
We use three rules to generate a tracing model: (lines 1-8) the endpoint rule
that creates the root of the tracing model and iterates over the transient link
582

Fig. 2. ATL Launch configuration dialogs
4.1 Tracing metamodel and model loading
When the transformation starts, an additional metamodel and an output model
are loaded. The metamodel is the Tracing metamodel and the model is the output
tracing model that conforms to the metamodel. The metamodel is internally
named TRACE and the model trace.
The TRACE metamodel is presented in Figure 3, and has a TransientLinkSet
meta-class and a TransientLink meta-class that replace the native types. Addi-
tionally, this metamodel has a TransientElement meta-class that represents a
source or target element in the transformation, and has the name of the rule
variable and a reference value to an EObject. This reference points to the actual
elements in the source and target models. Furthermore, using the EMF code
generation facilities, we implemented the native TransientLinkSet and Tran-
sientLink methods in an EMF plug-in. This EMF plug-in allows the visualiza-
tion of models conform to the TRACE metamodel and the transparent call
to the methods of the EMF version of the TransientLinkSet and TransientLink
inside the ATL-VM.
4.2 Bytecode adaptation
The second step is the bytecode adaptation, which occurs when the ASM file is
loaded. The adaptation replaces all the references to the native implementations
of TransientLinkSet and TransientLink by our proposed EMF versions. These
EMF versions are conform to the TRACE metamodel.
In the standard ASM code, the instances of TransientLinkSet and Tran-
sientLink are created by three contiguous instructions: 1) a push of the type
(TransientLinkSet or TransientLink), a push of #native and 3) the new in-
struction. When the ATM-VM executes these instructions a new native instance
is created. Our adaptation is done by replacing those push #native instruc-
tions by push TRACE instuctions. Therefore, when the ATL-VM executes the
adapted instructions, instances of our EMF metaclasses TransientLinkSet or
784

Leveraging Model Transformations by means of
Annotation Models
Juan M. Vara, Verónica A. Bollati, Belén Vela, Esperanza Marcos
Research Group Kybele
Rey Juan Carlos University
Madrid (Spain)
{juanmanuel.vara, veronica.bollati, belen.vela, esperanza.marcos}@urjc.es

Abstract. Model transformations are the key to automate any software
development proposal based on model-driven engineering. However, it might
happen that a unique transformation does not suit for every possible scenario.
This could be the case when the gap between source and target metamodels is
too large or the target metamodel is too complex. In such situations, it may
happen that the transformation never generates some constructions, unless its
execution is driven to do so. In other words, to obtain the most accurate models
we need to introduce some design decisions that guide the transformation. A
way to do so is to model our design decisions as annotations over the source
model – in a model-driven engineering context, everything should be a model.
Then, we can use such annotation model as an additional input for the model
transformation. This work shows how we have applied that technique to
improve our proposal for model-driven development of XML Schemas. The
solution is based on the use of weaving models as annotation models.
Key words: Model-Driven Software Development, XML Schema, Annotation
Models, Weaving Models.
1 Introduction
Since the World Wide Web Consortium (W3C) proposed the eXtensible Markup
Language (XML), it has become the current de facto standard for information
interchange between different organizations.
Initially, the way to define the structure of XML document was by declaring a
Document Type Definition (DTD). DTDs were very efficient at the beginning.
However, as the use of XML documents increased, the weaknesses of DTDs arose.
They present syntactic and semantic failings, especially when the structure of the
conforming XML documents is complex. For instance, they are not well-formed
XML documents, thus developers have to learn how to use two different syntax.
Besides, their mechanisms for defining arity are rather poor. To overcome these
drawbacks, the W3C proposed a new standard for defining the structure of XML
88

documents: the XML Schema Language [23]. It is an alternative to the use of DTDs
based on XML that provides a series of advantages with respect to DTDs.
The main improvement of XML Schemas regarding DTDs was providing with a
vastly improved data typing system. XML Schemas also support namespaces, which
allow different parts of a particular XML document to conform to different XML
Schemas [2]. All this given, the XML Schema has been commonly adopted as the de-
facto standard for XML document modeling.
In the line of the new trend in software development, in [4] we applied the
principles of the Model-Driven Engineering (MDE) approach [20] to the development
of XML Schemas. MDE proposes the use of models in each step of the development
process. Such models represent the Information System (IS) at different abstraction
levels. Besides, the transformation rules between these models have to be defined.
Our proposal starts from a Platform Independent Model (PIM) represented by a
UML class diagram. Next, a model to model transformation (M2M) generates a
Platform Specific Model (PSM) that represents the XML schema model. Finally, a
model to text transformation (M2T) generates the XML document that implements
the XML Schema model.
However, when we addressed the task of developing the tooling support for the
proposal we faced a common problem on MDE: we need some design decisions to
drive the PIM to PSM mapping. Nevertheless, according to the principles of MDE, a
development process must provide for the highest degree of automation. In fact, once
the PIM has been defined, the rest of the process should be completely automatic. The
simplest solution in this case is to use a default value for these design decisions when
coding the model transformation.
But defining a one-size-fits-all model transformation in such contexts is not
enough. It may occur that some constructions are never generated on the target model.
This approach could be improved by using a parameterizable transformation. Non-
uniform mappings [10] and generic transformations [21] were the first works in this
direction. Note that all the artefacts handled on a MDE process should be models. So,
the parameters we need to drive the execution of the transformation have to take the
shape of a model.
In this work we use a weaving model [1] as a container for those parameters or
design decisions. Before executing the model transformation, we define a weaving
model that annotates the source model. Then, both the source and the weaving model
are the inputs to generate the target model. This way, different target models can be
obtained from a particular source model, depending on which weaving/annotation
model is used.
The results lend strong support to the idea that current MDE tools, like model
transformations and weaving models are powerful enough to fulfill the requirements
of XML Schema development.
The rest of this paper is organized as follows. Section 2 briefly introduces two
MDE concepts: weaving models and annotation models. Section 3 presents the
proposal. To that end it describes the model-driven development process for XML
Schemas, the involved metamodels and the design decisions allowed when moving
from the PIM to the PSM. Section 4 focuses on the implementation of the proposal by
means of a case study. Section 5 summarizes related works. Finally, section 6 sums
up the main conclusions as well as the future work.
89

2.2 Annotation Models
MDA must support incremental and iterative development. This means that mappings
between models must be repeatable. So, if a mapping requires input in addition to the
source models, this information must be persistent. However, it must not be integrated
into the source model, because it would mean polluting the source with information
from outer domains, which is not desirable. These additional mapping inputs take the
form of annotations [15].
Models are annotated or decorated to insert information that is not defined in the
source metamodel. Annotation data usually is not conceptually relevant to be part of
the metamodel. For example, annotations are often meta-information used for pre-
processing, testing, logging, versioning, or parameterization [8].
The idea behind the use of model annotations for model transformation is the
following: a model transformation specifies a set of rules that encodes the
relationships between the elements from the input and output metamodels. Thus, it is
defined at metamodel level, i.e., it maps elements from the input and output
metamodels. It can be used to generate an output model from any model conforming
to the input metamodel. That is to say that the model transformation program works
for any model defined according to the input metamodel. However, in some situations
this approach could be too generic and some additional considerations have to be
made each time the transformation is executed. These considerations can take the
form of annotations and we can collect them in an annotation model.
For instance, given a PIM and a PSM metamodel, a model transformation between
them, and one terminal model conforming to the PIM metamodel, different PSM will
be generated for each annotation model used to execute the transformation. This is the
approach we follow in this work. Its application is showed in the following sections.
3 Automatic XML Schema Development in MIDAS framework
This work is framed in MIDAS [13], a model-driven methodology for IS
development. Specifically, our proposal focuses on the content aspect of MIDAS that
corresponds with the traditional concept of Database (DB). Fig. 2(a) summarizes the
development process. At PIM level we use a conceptual data model represented by an
UML class diagram. At PSM level, we use two different models depending on the
technology selected to implement the DB: the Object Relational (OR) model and the
XML model. In [4] and [5] we introduced the proposed MDE development process
for XML and OR technology, respectively.
In order to support the MIDAS framework we are building a MDE environment
for IS development called M2DAT (MIDAS MDA Tool). The work in this paper is
integrated in the M2DAT-DB (MIDAS MDA Tool – Database) module, which
provides the tooling for the content aspect of MIDAS.
All the technical solutions used to develop M2DAT share a common basis: they
are part of the Eclipse Modelling Project (EMP, http://www.eclipse.org/modeling/).
The EMP facilitates the deployment of any model-driven engineering process by
providing a unified set of modeling frameworks, tooling, and standards
91

implementations. All of theses facilities are built upon a common modelling
framework: the Eclipse Modelling Framework (EMF) [16]. Using EMF we have
developed the model editors for each metamodel considered in MIDAS.
For depicting the class diagrams used as conceptual data model at PIM level we
use UML2, the implementation of the UML 2.0 standard of EMF. To develop the
PIM to PSM model transformation we use the ATLAS Transformation Language
(ATL) [11]. Currently, ATL is considered the de-facto standard for M2M
transformations. It offers an Integrated Development Environment (IDE) completely
integrated in Eclipse. Besides, it is framed in the AMMA (ATLAS Model
Management Architecture) platform that includes other facilities in the MDE context,
such as the KM3 metamodeling language or the ATLAS Model Weaver (AMW) tool.
We have evaluated several proposals for code generation, such as MOFScript, JET
and XPand. Finally we are using the MOFScript [17] language. It is a prototype
implementation based on concepts submitted to the OMG MOF M2T transformations
RFP process [18]. Since it was the first submission to the OMG RFP, it is probably
the most contrasted and the most commonly used, despite the fact that recently XPand
and other template-based approaches are gaining ground. Besides, the training period
of MOFScript is quite short. After coding some M2M transformations, moving to
M2T transformations is quite easy.
As shown in Fig. 2(a), this work focuses on the transition from the conceptual data
model to the XML model. The first step towards the completion of this transition was
to define the mapping rules from PIM to PSM using graph grammars. Afterwards, we
coded these rules using ATL and finally, we coded the M2T transformation that
returns the XML Schema. For more details see [4].
However, by the time we were coding the ATL module, we realized that some
information needed to generate the target model was not included in the source
model. For each execution of the transformation some extra information was needed.
In some sense, this extra information can be shown as a way of parameterize the
transformation. In a first iteration we opted for using a set of default values for these
extra data. Nevertheless, it turned out that working this way, the transformation was
not able to produce some constructs on the target model, whichever the source model
used was. For instance, all the attributes of a particular XML element had to be
grouped using the same compositor, whether it was sequence, choice or all. We will
show a detailed example in the following sections.
The first option to overcome this drawback was to extend the source metamodel to
support the modeling of this extra information. However, it is not fair to pollute the
metamodel with concepts not relevant for the domain that it represents. Back to the
mentioned example, the decision on how a set of PIM attributes should be mapped to
an XML Schema model is a platform specific matter. It should not be considered
when defining the PIM and it should not have any influence on the way we define the
PIM.
Therefore, we needed a different way to collect this extra information that was
related to the source model but not included in it. Since this information or
parameters had to be available for the ATL program and considering that we were in
a MDE context, the best option was to use another model (and thus to define a new
metamodel): an annotation model.
92