Using Aspect-Oriented Programming to Trace Imperative Transformations

Bastien Amar, Herve Leblanc, Bernard Coulette

IRIT, Universite Paul Sabatier,118 Route de Narbonne,

F-31062 Toulouse Cedex 9{amar,leblanc,coulette}@irit.fr

Clementine Nebut

LIRMM,161 rue Ada,

34392 Montpellier Cedex 5 France,nebut@lirmm.fr

Abstract—With the advent of languages and tools dedicatedto model-driven engineering (e.g., ATL, Kermeta, EMF), aswell as reference metamodels (MOF, Ecore), model-driven de-velopment processes can be used easily. However, the maturityof a software engineering technology should be evaluated bythe degree of use of traceability practices. One of the firstmajor challenges consists in generating automatically traceinformation during a transformation process. Our contributionis a tool dedicated to infer traces during the execution of amodel transformation. This tool is based on aspect orientedprogramming which permits us to isolate management of tracesand imperative transformations code in a Java/EMF environ-ment. A meta-model of nested traces allows the visualisation oftraces as nested graphs which represent the traceability linksand the control flow diagram of the execution. A model-to-model case study is proposed as an example to illustrate ourcontribution.

Keywords-traceability, model-driven engineering, modeltransformation.

I. INTRODUCTION

With the advent of languages and tools dedicated to

model-driven engineering (e.g., ATL [1], Kermeta [2], EMF

[3]), model-driven development processes can be more easily

used. Model Driven Engineering allows models to be consid-

ered as data and then used as first class entities in dedicated

transformations. As a result, the recurrent problems linked to

software production are emerging in this new development

context. Traceability practice is part of the measure of

software process maturity. Thus MDE processes should

include traceability in their life cycle, in particular since

they are based on a large range of models and transfor-

mations covering the whole software development lifecycle,

e.g. from requirements and business models to platform

and implementation models, using weaving or refinement

transformations.

The requirements management community is the origina-

tor of the traceability concept [4]. A definition of traceability

links adapted to model traceability is given in [5], they are

defined as: “Explicit links or mappings that are generated asa result of transformations”. Our contribution is connected

to this definition. Transformations are generally expressed in

dedicated languages like ATL, Kermeta, and QVT compliant

languages. However some complex transformations lead to

a significant part of imperative code. We choose to deal

with transformations written with the Java EMF libraries.

It is the basis of all transformations tools that run on

the Eclipse environment and we can use object-oriented

practices to structure code. Then, we propose an EMF

plug-in which “stalks” any event to infer traceability links

during a Java/EMF transformation. We use aspect-oriented

programming to hunt transformation events in Java programs

and we store trace links conform to a nested traces meta-

model. Contrary to declarative transformation languages,

we cannot infer traces by rules analysis. Aspect-oriented

programming allows us to infer trace links from coding

patterns.

Our contribution is an original way to trace imperative

model transformations, based on aspect-oriented program-

ming to catch the transformation events, and on composite

trace links to ease the use and the visualization of the

trace. It is positioned w.r.t related work in section II. Then

Sections III and IV detail the core of our contribution:

the trace metamodel, and the way the trace model is built

catching transformation events thanks to aspect-oriented

programming. Section V details the results of our approach

on a case study.

II. RELATED WORK AND OVERVIEW OF THE APPROACH

A. MDE and Traceability

Adopting a Model-Driven Engineering (MDE) approach

requires to intensively handle model transformations during

software development, and tracing those transformations

has been identified as an important issue [5], [6]. In this

section, we briefly review the existing proposals concerning

traceability in MDE, and draw from this review the main

principles of our approach.

With the UML, and then Model Driven Architecture

(MDA [7]), the OMG gave to modeling and metamodeling

a revival of interest, and is still an important actor of MDE.

In the Query View Transformation proposition [8], the OMG

proposes to associate each relation with a specific Trace

Class and to automatically generate traces during a transfor-

mation without a decision of the designer. A relationship is a

subset of the Cartesian product of n domains. Each domain

corresponds to a meta-class that conform to the meta-object

2010 14th IEEE International Enterprise Distributed Object Computing Conference

1541-7719/10 $26.00 © 2010 IEEE

DOI 10.1109/EDOC.2010.12

143

facilities (MOF) and a relationship is considered as the sig-

nature of a model transformation. These recommendations

aim at performing incremental transformations: only relevant

parts of source models are taken into account.

Tools based on QVT or TGG exist and generate traces.

However, nothing is said about the implementation of traces

in the OMG standard for QVT. For declarative language,

traceability is provided by the analysis of transformation

rules. But in some transformation, an important part of code

can be included in the “helper”, which is an imperative part,

often not traced.

A state of the art survey on traceability in Model Driven

Engineering is proposed in [6]. The authors evaluate all the

studied approaches using the following criteria: representa-

tion, mapping, scaling, impact analysis, and tooling. The ap-

proaches are partitioned into three groups: those concerning

requirements engineering in MDE processes, those focusing

on models or meta-models allowing to store information

about trace transformation or evolution, and those aiming

at generating traces during model transformations. Like the

approaches proposed in [9], [10], [11], [12], our approach

is part of this last group: we track transformational events

(update, delete and create) during imperative transformations

and organize them in a trace model. The authors of [6] also

suggest three good practices for this kind of traceability:

• to isolate trace models from other models;

• to use a well-designed meta-model;

• to use dedicated tools to support traceability: trace-

ability should not be a property of a transformation

language.

Our proposal has been designed following those good prac-

tices.

B. Related Work and Proposed Solution

Reference [9] is a proposal to include traceability issues

in the ATL environment: a dedicated program adds code to

some ATL model transformations for generate traces. This

program is executed at the pre-compilation phase, on the

abstract syntax of the ATL code. This transformation gener-

ates traces only for the declarative part of the transformation

rules. In contrast, [10] proposes to manually generates traces

for imperative transformations.

An analysis of traceability patterns is proposed in [12].

Transformations are expressed in a QVT-Relation language

and traces are used to predict which QVT-Relation rules

must be rerun when source model modifications appear.

The different patterns induce different policies regarding

the rules to run again. A complementary work is proposed

in [11]. This work focuses on the operational part of a

transformation language. A signature is associated to each

helper and permits an impact analysis based on update

and delete rules applied on source elements. Relation rules

are used to manage transformations between structurally

equivalent models. Helper rules are designed to manage

other types of transformations.

Our proposal is original w.r.t the work proposed in [9],

[10], [11], [12] in the sense that it focuses on the generation

of traces in the context of imperative model transformations,

and not declarative model transformations. The transforma-

tion events thus cannot be caught the same way.

Four main requirements inspired by the best practices

from the literature have driven our approach:

• The trace models must be isolated both from the source

and the target models involved in the transformation.

Creating an independent trace metamodel makes all the

models independent, and avoids enhancing the original

metamodels with trace information. Moreover, merging

traceability links and models on demand is proposed in

[13].

• The generated trace models should be read using differ-

ent levels of granularity, e.g. low-level transformation

details, or high-level transformation procedures.

• The trace generation code must not be intrusive in the

transformation code: the transformation code and the

code necessary to generate the trace of the transforma-

tion should not be mixed.

• The trace generation functionality must be easily en-

abled or disabled, since tracing a transformation can

alter its efficiency, and is not necessary at each phase

of development.

The two first points are achieved by building a trace

that conform to a meta-model supporting composite trace

links (Section III). The third and the fourth points are

achieved by the aspect-oriented programming mechanisms

(Section IV). Figure 1 presents the overall architecture of

our proposal, ETraceTool. The frame at the top represents

the environment, which is composed of a source model

and an imperative transformation, coded in Java with the

EMF API. The EMF project includes a reference meta-

meta-model (Ecore), and a reflexive API used to handle

models (which conform to Ecore [3]), and in particular to

program model transformations. During the execution of a

Trace Model XMI

Source Model Target Model

Conforms toTrace Metamodel

Nested

Catching transformation events

Annotated Graph

Visualisation /Debugging

Imperative Environment

Serialisation

Aspect Tracer

Transformation writtenin Java/EMF

Figure 1. General ETraceTool architecture

144

given transformation, the transformation events (e.g. creation

of a model element) are inferred and caught (by the aspect

tracer), then they are added to a trace model. At the end

of the transformation execution, the trace model can be

serialized in the XMI format, or visualized in the form of

an annotated graph, used for other purposes.

III. A NESTED TRACES METAMODEL

Tracing model transformations requires the gathering of

information on the way models evolve during a given pro-

cess composed of several model transformations. In ETrace-Tool, a dedicated trace model is built for each execution

of a model transformation. This model conforms to a trace

meta-model designed to structure the traces with a composite

design pattern. Indeed, when all the transformation events

are represented, a trace is usually a complex artifact, even

for a small transformation: a transformation method calls

another transformation method, or a rule implies the appli-

cation of another, so that the trace results in a large hyper-

graph with nested calls or nested rule application. To be

useful, the trace should be folded and unfolded on demand,

similarly to the way a debugger acts: a user can step into or

step over a method. This requirement guided the design of

our trace metamodel. The trace metamodel is not specific to

imperative transformations.

Several trace metamodels have already been proposed in

the literature [9], [10]. They support most of the trans-

formations that can occur in an MDE process: they are

general-purpose traceability metamodels according to [14].

The core of the trace concept was presented in [9]: a trace

link is composed of a set of sources and a set of target

elements. It is a simple trace model dedicated to declarative

transformations, then the traces are encoded by a bundle

of links represented as a set of source elements reached to

a set of target elements. The first extension of the trace

notion given by Jouault is to consider a trace as a set of

bipartite graphs with a common intersection [10]. A step

artefact allows chain-transformation (several transformations

performed successively on models) to be managed. Here,

traces rely one source element to one target element.

Our proposal gathers the benefits from the two ap-

proaches: there are basic links for the precision requirement,

and also composite links for the fold/unfold mechanism.

Our metamodel (see Figure 2) extends the one proposed

in [10] by injecting a composite pattern. Each step can be

represented by a composite link. Moreover, the composite

pattern allows us to manage multiscaled traces. Indeed, when

an operation calls other ones or when rules trigger other

rules, nested levels should be represented in the trace. Nested

traces allow the final user to examine a trace at different

levels of granularity, from rough to precise. In order to obtain

such nested traces, the composite pattern [15] is applied

on the links, leading to the metamodel shown in figure 2.

As explained in [16], we use the composite to represent

imbrications of operation calls. It allows us to structure trace

links.

����������

�� ������

����� �����

��������� � ����������������� �

���

���������������� ���������������� ������������� ���������������� ������������������������������ �������������� ��������� �������������

������

���������� �����������

������������

���������

�������

!

�������

!

��"��!##$����%&��

$��&��

!

Figure 2. A nested trace metamodel

We present in the next Section how we catch transfor-

mation events and generate a trace conform to our trace

metamodel during a model transformation.

IV. USING ASPECT ORIENTED PROGRAMMING TO CATCH

CATEGORIZED EVENTS

In this section, we show how we use aspect oriented

programming to trace an EMF transformation. Analyzing

and tracing imperative transformation code is a complex

task due to the possible different styles of programming

(e.g. one main class with one main method versus a good

object-oriented programming style). We defined heuristics

on how to trace the various operations present in a model

transformation. First, we present the main concepts of aspect

oriented programming used to capture traces.

A. Aspect oriented programming

Aspect oriented programming [17] perfectly fits our re-

quirement for the ETraceTool to build the trace without mod-

ifying the code of the transformation. Indeed, programming

by aspects allows us to gather in a single piece of code (an

aspect) a crosscutting concern usually distributed in several

classes. A classical example of an aspect is persistence, and

here we use it to deal with trace generation. We have chosen

AspectJ 1 to implement the aspects in ETraceTool. An aspect

is mainly defined by:

• pointcuts: they are regular expressions used to deter-

mine the places where the source code has to be added

to the initial application code, and also to define when

those additions have to be carried out. A pointcut

is defined by a dedicated language based on regular

expressions.

1http://www.eclipse.org/aspectj

145

• advice: they are the pieces of code that will be added

or woven in the application, and they are reached to a

pointcut. In AspectJ, there are three types of advice:

– before: they are woven before the source code

pointed out by the associated pointcut;

– after: they are woven after the source code pointed

out by the associated pointcut;

– around: they are woven around the source code,

using the keyword proceed: the code before (resp.

after) the keyword proceed is woven before (resp.

after) the original code.

AspectJ can weave code at the compilation or at the load-

time. We choose to weave code at compilation time. How-

ever, if the user does not have the transformation code,

load-time weaving can be considered. The trace generation

code is defined in around advice. Before the execution of

an intercepted operation, we create trace links and assign

for each link a source model element, retrieve by using the

thisJoinPoint.getArgs method. After the execution

of the considered operation, targets are assigned with the

returned object of the proceed method that permit the

execution of the operation.

B. Categorization of operation and pointcut for weaving

ETraceTool aims at generating in an automated way a

trace for a model transformation written in an imperative

language, namely Java/EMF. Thus the program of the model

transformation we deal with is an object-oriented program,

composed of classes and methods/operations, handling basic

java objects as well as particular objects representing model

elements.

After studying Java/EMF programs, we have classified

operations that can be found in model transformations into

six categories that have to be traced in a different way. For

each category, we have defined a dedicated pointcut to trace

them, and a particular treatment in the resulting trace.

1) Functional operations: To illustrate this category, let

us take the example of the following user-defined operation2:

EClass makeSuperClass(EClass c1, EClass c2)

This operation takes as a parameter two EClass c1 and

c2, merges them and returns a superclass factorizing the

common attributes of c1 and c2. Tracing this operation

consists in creating links between the returned object (the

target) and the objects c1 and c2 (the sources). From this

example, we can formulate the following heuristics: each

time an operation takes for parameter at least one EObjectand returns an EObject, the parameters are the sources of

traceability links and the returned object is the target of each

traceability link. The corresponding pointcut is defined as

follows:

pointcut FunctionalMethod():

2Examples are taken from the case study presented in Section V

call(EObject+ * (..,EObject+,..))

A method call is represented by the keyword call. It

takes parameters in order to specify the method to intercept.

Parameters are organized as follows:

• the return type, here EObject+, means that the type

of the returned object must be an EObject or one of its

subclasses (using the + symbol).

• the name of the operation, here: * that intercepts all the

operations.

• the parameters of the method, here:

..,EObject+,.. means that neither the number

of the parameters nor their type does matter, the only

requirement is to have at least one parameter of type

EObject+.

The inferred trace links are built as follows:

• First, the functional link are inferred from the operation

signature. Each of the EObject parameters is the source,

and the returned element is the target of each created

links. Sources are assigned before the execution of the

operation and targets are assigned after.

• A composite link is created if and only if sublinks are

created during the operation execution.

2) Procedures: the procedure pointcut only structures the

trace. A procedure is an operation that deals with EObject

and that is not categorized as functional. When a procedure

is called, a composite link is created and added to the trace

if some links are generated during the execution of the

procedure. For example:

void AddInheritanceLink(Class subclass,Class superclass)

is a procedure. It leads to the definition of the following

pointcut:

pointcut procedure():call(!EObject * (.., EObject+, ..))

3) Factory pattern: Creation of model elements using

the Factory design pattern. When programming a model

transformation using EMF, the objects are created using

the Factory design pattern: each object is created using

dedicated methods in the singleton class EFactory (or one of

its subclasses). In the corresponding trace, the newly created

object thus has to be linked to the class EFactory, playing

the role of source. We thus define a category of operations

allowing newly created objects to be detected. For instance,

to create a property in the UML environment based on EMF,

we use:

Generalization g =UMLFactory.eINSTANCE.createGeneralization();

The corresponding poincut code is the following:

pointcut FactoryMethod(EObject receiver):call(EObject+ *(..)) && target(receiver) &&if(receiver instanceof EFactory)

146

The keyword target and the receiver parameter are

used to retrieve the EObject that receive the message.

Here, the EObject receiver must represent a factory single-

ton. The treatment for this category is to create a trace link

in which the source is the factory used, and the destination

is the newly created object.

4) Mutators: There is no constructor with parameters

in EMF. Mutators are used to initialize features of newly

created objects. They are easy to detect, their call look like

this example:

generalization.setSpecific(subClass);

Indeed, they do not have a return type or their return type

is not a sub-class of EObject. The receiver of the mutator call

is an EObject and has a single parameter of type EObject.

Note that the type of the returned element must not be an

EObject (represented by the !EObject statement), so that

this category does not interfere with the functional category.

The following pointcut has been defined for this category:

pointcut SetterMethod(EObject receiver):call(!EObject+ *(..,EObject+,..))&&if(receiver instanceof EObject)&&target(receiver);

The treatment when this category is found is to create

a link for which the EObject parameter is the source, and

the modified element is the target. In our point of view, the

parameter is the originator of this micro-transformation.

5) Add operations: Model elements added to a container.

In the EMF framework, the addition of a model element to

its container is performed by the call of an add method to

an EList instance.

current.getOwnedTypes().add(extractSuperClass(a,b))

The corresponding pointcut is given below.

pointcut addItem() :call(* EList.add*(..));

When an occurence of this category is found, the process-

ing to carry out is to create a trace link in which the source

is the added object, and the target is the object owning the

collection to which the EObject is added.

6) Remove operations: Model elements removed from a

container.

a1.getClass().getOwnedAttributes().remove(a1)

The expression of this category is similar to the Addoperations one and the poincut detecting such a category

is defined as follows:

pointcut removeItem() :call(* EList.remove*(..));

The corresponding treatment is slightly more complicated

than for the Add operations category. A trace link is created:

the source is the removed object, and the target is a generic

container named Trash. This category is a priori only used

in refactoring transformation. The trash is used to save the

references to removed objects. This way, those elements still

exist in the model and can thus be used in the trace, and also

used again in the model when necessary.

Note that the designer of a transformation must give the

scope of the transformation code that he or she wants to

trace. Then, we have defined a last pointcut to define the

entry point of the transformation, that is supposed to be a

method named transform:

pointcut TransfoExec():execution(* transform(..));

V. EXPLOITATION AND VALIDATION OF THE TRACE

In this section, we present the results of our approach

using a refactoring example.

A. The refactoring example

The example used is a refactoring written in Java EMF.

It is an abstraction at design model level of a code refac-

toring proposed by Martin Fowler [18]: the transformation

detects pairs of classes owning identical attributes, creates

a common superclass and moves common attributes in the

superclass. This transformation is endogenous (from UML to

UML) and horizontal according to the classification criteria

given in [19]. The main code for this transformation is given

in listing 1 and 2.

GeneralizationProcess is the main class of the

transformation. The main method loads the model to refac-

tor and assigns the current Package instance variable with

the corresponding Package. We want to trace the whole

refactoring, thus the transform method is immediately

called. Finally, the refactored package is serialized. In the

transform method, for each couple of classes that share

an attribute, the method extractSuperClass is called.

Using EMF, all classes of the meta-metamodel ECORE

are derived from java classes and all classes of the meta-

model UML are derived from ECORE classes. Classes

prefixed by the letter E are owned by an ECORE package.

UML meta-classes handled by the refactoring are: Class,

Generalization, NamedElement, Package, and

Property.

The meta-model UML 2.1 API provided by the Eclipse

Modeling Framework scrupulously respects the UML stan-

dard. Navigable roles of associations in a metamodel are

obtained using the corresponding getter method: for exam-

ple the method getOwnedTypes is used to navigate the

ownedTypes feature.

Listing 2 details the core mechanisms of the refactoring.

Methods respectively named extractSuperClass and

pullUpField implements Fowler’s refactoring motiva-

tions:

147

p r i v a t e Package c u r r e n t ;

p u b l i c s t a t i c vo id main ( S t r i n g [ ] a r g s ){c u r r e n t = ( Package ) M o d e l U t i l i t y . ge tModel ( ” s o u r c e . uml ” ) . getMembers ( ) . g e t ( 0 ) ;

t r a n s f o r m ( g e t C l a s s e s ( ) ) ;M o d e l U t i l i t y . s ave ( c u r r e n t , ” t a r g e t . uml ” ) ;

}

p r i v a t e ELis t<Class> g e t C l a s s e s ( ) {ELis t<NamedElement> namedelement = c u r r e n t . getMembers ( ) ;ELis t<Class> l i s t = new B a s i c E L i s t<Class > ( ) ;f o r ( NamedElement n : namedelement )

i f ( n i n s t a n c e o f C l a s s )l i s t . add ( ( C l a s s ) n ) ;

re turn l i s t ;}

p u b l i c vo id t r a n s f o r m ( ELis t<Class> c l a s s e s ) {f o r ( i n t i =0 ; i<c l a s s e s . s i z e ( ) ; i ++) {

f o r ( i n t j = i +1 ; j<c l a s s e s . s i z e ( ) ; j ++) {C l a s s a = ( C l a s s ) c l a s s e s . g e t ( i ) ;C l a s s b = ( C l a s s ) c l a s s e s . g e t ( j ) ;i f ( n e e d R e f a c t o r i n g ( a , b ) )

c u r r e n t . getOwnedTypes ( ) . add ( e x t r a c t S u p e r C l a s s ( a , b ) ) ;}

}}

p u b l i c boolean n e e d R e f a c t o r i n g ( C l a s s a , C l a s s b ) {f o r ( P r o p e r t y a A t t r : a . g e t O w n e d A t t r i b u t e s ( ) )

f o r ( P r o p e r t y b A t t r : b . g e t O w n e d A t t r i b u t e s ( ) )re turn e q u a l s A t t r i b u t e s ( a A t t r , b A t t r ) ;

re turn f a l s e ;}

p r i v a t e boolean e q u a l s A t t r i b u t e s ( P r o p e r t y a , P r o p e r t y b ) {re turn a . getName ( ) . e q u a l s ( b . getName ( ) ) && a . ge tType ( ) . e q u a l s ( b . ge tType ( ) ) ;

}

Listing 1. Launching code

Extract Superclass: you have two classes with similar

features, then create a superclass and move the common

features to the superclass.

Pull up Field: two subclasses have the same field, then

move the field to the superclass.

Extract Superclass calls Pull up Field: one by one, use

Pull up Field to move common elements to the superclass.

We consider these two methods as high-level or user-

defined operations. These methods return the model ele-

ments they created. extractSuperClass successively

creates a super class, computes the couples of prop-

erties to factorize, performs the corresponding calls to

pullUpField, and adds the generalization links. The class

Couple is a basic templated inner class. The algorithm of

pullUpField clones one of the properties, removes the

considered properties from the classes, and adds the cloned

property to the super class.

Finally, the platform-dependent code in Java EMF is

found in the following low-level operations:

The creation of each type of modelling artefacts is dele-

gated to a specific instance method on a Singleton-Factory

class. The UMLFactory.eINSTANCE unique instance

plays the role of the factory of all UML model elements.

Each type of artefacts is instantiated by the corresponding

method create<TypeArtefact>. The creation of an

artefact does not imply the persistence of it in the results

model. In fact we must reach an element to a model or to

a container of elements: package, class . . .The addition or removal of a model artefact is performed

by the same operation on a list of artefacts contained by the

appropriate container of model elements, for example: the

addition of an attribute to a class container, the addition of a

generalization to the set of generalizations owned by a class,

and the addition of a class to a package container.The cloning of an attribute is performed thanks to the

copy method provided by the EcoreUtil class. This

method allows a deep copy of any EObject to be per-

formed.

B. Visualizing the traceWe present here the way we visualize the trace models

generated by ETraceTool, in the form of annotated graphs,

using the graphviz tool [20]. Visual modelling usually helps

148

p u b l i c C l a s s e x t r a c t S u p e r C l a s s ( C l a s s a , C l a s s b ) {C l a s s r e s u l t = UMLFactory . eINSTANCE . c r e a t e C l a s s ( ) ;r e s u l t . setName ( a . getName ( ) + ” ˆ ” + b . getName ( ) ) ;ELis t<P r o p e r t y> a A t t r i b u t e = a . g e t O w n e d A t t r i b u t e s ( ) ;ELis t<P r o p e r t y> b A t t r i b u t e = b . g e t O w n e d A t t r i b u t e s ( ) ;ELis t<Couple<P r o p e r t y>> t o F a c t o r i z e = new B a s i c E L i s t<Couple<P r o p e r t y >>();f o r ( P r o p e r t y a A t t r : a A t t r i b u t e )

f o r ( P r o p e r t y b A t t r : b A t t r i b u t e )i f ( e q u a l s A t t r i b u t e s ( a A t t r , b A t t r ) )

t o F a c t o r i z e . add ( new Couple<P r o p e r t y >( a A t t r , b A t t r ) ) ;f o r ( Couple<P r o p e r t y> c : t o F a c t o r i z e )

p u l l U p F i e l d ( c . g e t F i r s t ( ) , c . ge tSecond ( ) , r e s u l t ) ;r e s u l t . s e t I s A b s t r a c t ( t rue ) ;a d d I n h e r i t a n c e L i n k ( a , r e s u l t ) ;a d d I n h e r i t a n c e L i n k ( b , r e s u l t ) ;re turn r e s u l t ;

}

p u b l i c P r o p e r t y p u l l U p F i e l d ( P r o p e r t y a1 , P r o p e r t y a2 , C l a s s t a r g e t ) {P r o p e r t y r e s u l t = c l o n e ( a1 ) ;a1 . g e t C l a s s ( ) . g e t O w n e d A t t r i b u t e s ( ) . remove ( a1 ) ;a2 . g e t C l a s s ( ) . g e t O w n e d A t t r i b u t e s ( ) . remove ( a2 ) ;t a r g e t . g e t O w n e d A t t r i b u t e s ( ) . add ( r e s u l t ) ;re turn r e s u l t ;

}

p r i v a t e P r o p e r t y c l o n e ( P r o p e r t y eo ) {re turn ( P r o p e r t y ) E c o r e U t i l . copy ( eo ) ;

}

p u b l i c vo id a d d I n h e r i t a n c e L i n k ( C l a s s subCla s s , C l a s s s u p e r C l a s s ) {G e n e r a l i z a t i o n g = UMLFactory . eINSTANCE . c r e a t e G e n e r a l i z a t i o n ( ) ;g . s e t G e n e r a l ( s u p e r C l a s s ) ;g . s e t S p e c i f i c ( s u b C l a s s ) ;s u b C l a s s . g e t G e n e r a l i z a t i o n s ( ) . add ( g ) ;

}

Listing 2. Refactoring code

to understand a system and to maintain consistency among

its different artefacts. However transformation traces are

rarely visualized. Trace visualization can be used to debug

an imperative transformation [16]. An MDE process is

usually seen as a succession of transformations, and the

traces are classically used to explore and navigate into

traceability information [21]. Displaying traces as lines

connecting elements makes diagrams very complex and does

not really illustrate the transformation links complexity and

granularity. We have chosen to focus on the execution of

a transformation process by emphasizing data-flow (in, out

and in-out model elements) and method calls.

We executed our refactoring transformation on a basic

source model that contains two classes A and B with a

common boolean attribute named a. Then, the target model

contains the two classes A and B from which was deleted the

attribute a and a common super class A ∧ B that factorizes

this attribute. Figure 3 represents the obtained trace for this

execution.

Nested traces: there are two types of trace links.

A simple link represents an inferred transformation event

between a source and a target model element. A composite

link is a non-empty set of links that represents a call to a

transformation routine. Then we have a nested traces graph

that is isomorphic to the method calls. Nested traces are

represented by boxes labeled with the corresponding method

name. The transform method is the root of the nested

graph because it is the starting point of the transformation

execution listening. Then the ExtractSuperClass box

includes the PullUpField box.

Theoretically the trace is a simple directed graph with

labeled nodes and edges. In practice, we obtain a multi-graph

because we have inferred some links at different levels of

functional decomposition. For example there are two edges

between the attribute a of either Class A or B and the cloned

attribute of the super-class A ∧ B. One of these edges is

labeled with the low-level clone operation and the other

with the pullUpField method that invokes the clonemethod.

Filled nodes represent model elements that are created by

a factory during the transformation while the other nodes

represent the source or intermediate model elements. Solid

lines started from a factory represent the creation of a model

element from the corresponding factory. Other solid lines

without label represent the addition of a model element

to its serializable container. We can see that attributes a

149

��������

������ ��������

����������

��������������������������������

��������

�����

�

����������

�����!�����

�� ����

�����!�����

�� ����

"����#$�%������

�

��������������

$%� &

�

����������

��������

�

������ ��������

�� ���'�

��������

�

������ ��������

�� ���'�

Figure 3. Trace graph generated by ETraceTool

in classes A and B are not definitely deleted. There are

saved in a generic container named Trash. Finally, solid

labelled lines represent high-level transformation links or

user-specific operations. and dashed lines represent low-level

transformation links (of API-specific operations).

The dot algorithm places the nodes in the deeper box

where the model element appear in a link. Then the class

A ∧ B appears in the pullUpField box because the ad-

dition of the cloned attribute a is executed during this

method. Therefore this class was created in the scope of

the extractSuperClass Method. For the same reason

the package packageToRefactor appears in any box.

This view of the transformation is based on the hierarchical

structure of the functional decomposition of the transforma-

tion.

This trace graph can be considered as a static visualization

of a transformation execution. It can be used as a debugging

transformation tool, helping to discover the wrong actions

performed during the transformation. We can easily generate

a sub graph directed by the scope of a transformation method

or by elements model type involved in a transformation

process.

C. Evaluation of the Approach

To evaluate the relevance of our approach, we use metrics

such as recall and precision [22] that we adapt to our context.

In information retrieval contexts, precision and recall are

defined in terms of a set of retrieved documents (e.g. the list

of documents produced by a web search engine for a query)

and a set of relevant documents (e.g. the list of all documents

on the internet that are relevant for a certain topic). We adapt

this measure to our context, in order to evaluate the relevance

of the trace we obtain. Intuitively, they allow to answer to

the two questions :

• recall: does our platform forget relevant traces ?

• precision: are the traces retrieved by our platform

relevant ?

Given a transformation T and a source model s, let |Lt|the total number of leaf links obtained by our platform (i.e.links must not be composite: the structure is expected but

not predictable). |Lr| is the number of relevant links for a

given transformation and |Le| is the number of relevant links

obtained by our platform. A relevant link3 is an expected and

predictable traceability link which must occur in the trace

of the transformation T applied on the model s.

Recall R =|Le||Lr| Precision P =

|Le||Lt|

We computed these metrics on the given example. To

validate our approach, we developed a more substantial

transformation in two different ways. This transformation is

a refinement of an UML interactions diagram. The obtained

results are presented in table I.

3The relevant links of the example are detailled on: http://www.irit.fr/Herve.Leblanc/expected trace.pdf

150

Recall: : According to all the tests we made, all

elements in the target model are referenced in a trace link

and we obtain all the relevant traces. However, our platform

traces only methods dealing with EObject. That means

that methods dealing with primitive types or non-EObjectelements are not traced. For instance, a setter method that

takes a String object as parameter is not traced, like the

setName operation in the refactoring code.

Precision: : The number traces that are not relevant is

large, mainly for three reasons:

• the query operations. In imperative model transforma-

tions, there are some operations just used to query

models. For instance, an operation Package findTop-Package(Class c) will be traced by our platform as a

functional operation, and the c class will be linked to

the returned package. This link is not relevant for the

transformation.

• the creation of a model element implies the use of

a factory method and the adding of the element to a

serializable container.

• the metamodel. The transformation of an element in-

volves the transformation of many elements associated

with it, due to the complexity of the UML metamodel.

Recall R Precision P Lt

Refactoring 1 0, 42 24Refinement v1 1 0, 26 246Refinement v2 1 0, 22 296

Table IRECALL AND PRECISION ON SOME TRANSFORMATIONS

Please note that the two refinements are applied on UML

sequence diagrams. A trace between two graphical elements

in the UML notation is actually multiples trace between

multiple elements, due to the complexity of the UML meta-

model. For example a trace between two UML Messages

is in fact traces between Message, two MessageOccurence-

Specifications, CallEvent, and Operation. All these traces are

taken into account for the precision computation.

This low precision is due to the fact that all information

concerning the execution of the transformation is included

in the trace. These traces are valid, they represent the

internal processing of the transformation. However, they are

not considered as relevant considering the definition given

above. To keep only relevant traces, we can execute queries

on the trace model. Moreover, we are currently developing

a trace type system to isolate the relevant traces of the

execution links.

VI. CONCLUSION AND PERSPECTIVES

In this paper, we presented a new approach and tool

dedicated to automatically trace imperative model trans-

formations. We use aspect oriented programming to catch

transformation events in order to infer and structure trace-

ability links. Thanks to our nested trace metamodel, the

trace structure follows the functional decomposition of the

transformation. In the DOMINO ANR National Research

Agency project [23], we developed more substantial transfor-

mations to study co-evolution issues. With the visualization

of traces which is similar to a control flow diagram of

the transformation execution, we were able to correct and

validate them. We believe that our tool can be integrated in a

continuous improvement process of model transformations.

Several perspectives to our work are under considera-

tion. We are formalizing more precisely the traces obtained

with regard to the expected traces and apply Etracetool on

substantial transformations, and we are developing a set of

metrics that will allow us to estimate the quality of a trans-

formation through trace analysis. Finally, we successfully

applied our platform to industrial transformations taken from

the aerospace field. To be able to exploit the obtained traces,

we have to extend our platform to transformations which

manage multiple inputs and outputs.

REFERENCES

[1] F. Jouault, “Contribution to the study of model transformationlanguages,” Ph.D. dissertation, Universite de Nantes, 2006.

[2] Z. Drey, C. Faucher, F. Fleurey, and D. Vojtisek, Kermetalanguage reference manual, 2006. [Online]. Available:http://www.kermeta.org/documents/manual/

[3] F. Budinsky, J. T. Grose, D. Steinberg, R. Ellersick, andE. Merks, Eclipse Modeling Framework: a developer’s guide.Addison-Wesley Professional, 2003.

[4] IEEE, “Standard Glossary of Software Engineering Terminol-ogy: IEEE Std 610.12-1990,” IEEE, Tech. Rep., 1990.

[5] N. Aizenbud-Reshef, B. T. Nolan, J. Rubin, and Y. Shaham-Gafni, “Model traceability,” IBM System Journal, vol. 45,no. 3, pp. 515–526, 2006.

[6] I. Galvao and A. Goknil, “Survey of traceability approachesin model driven engineering,” in the Eleventh InternationalIEEE EDOC Conference (EDOC 2007). IEEE ComputerSociety Press, 2007.

[7] OMG, “MDA Guide v1.0.1,” 2003.

[8] OMG, “Submission for mof 2.0 query/view/transformation.”

[9] F. Jouault, “Loosely coupled traceability for ATL,” inECMDA-Traceability Workshop, Nuremberg, 2005.

[10] J.-R. Falleri, M. Huchard, and C. Nebut, “Towards a trace-ability framework for model transformations in Kermeta,” inECMDA-TW 2006 Proceedings, Bilbao, July 11th 2006, 2006.

[11] I. Kurtev, M. Dee, A. Goknil, and K. van den Berg,“Traceability-based change management in operational map-pings,” in ECMDA-TW 2007 Proceedings, Haifa, Israel, June12th, 2007.

151

[12] K. Van Den Berg, B. Tekinerdogan, and H. Nguyen, “Analysisof Crosscutting in Model Transformations,” in ECMDA-TW2006 Proceedings, Bilbao, July 11th 2006, 2006.

[13] D. S. Kolovos, R. F. Paige, and F. A. Polack, “On-demandmerging of traceability links with models,” in ECMDA-TW2006 Proceedings, Bilbao, July 11th 2006, 2006, pp. 7 – 15.

[14] N. Drivalos, R. F. Paige, K. J. Fernandes, and D. S. Kolovos,“Towards Rigorously Defined Model-to-Model Traceability,”in ECMDA Traceability Workshop 2008, Berlin, 2008, pp.17–26.

[15] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, DesignPatterns - Elements of Reusable Object-Oriented Software.Addison-Wesley Professional, 1995.

[16] B. Amar, H. Leblanc, and B. Coulette, “A Traceability EngineDedicated to Model Transformation for Software Engineer-ing,” in ECMDA Traceability Workshop 2008, Berlin, june2008, pp. 7–16.

[17] G. Kiczales, J. Lamping, A. Menhdhekar, C. Maeda,C. Lopes, J.-M. Loingtier, and J. Irwin, “Aspect-oriented pro-gramming,” in Proceedings European Conference on Object-Oriented Programming, vol. 1241. Springer-Verlag, 1997,pp. 220–242.

[18] M. Fowler, K. Beck, J. Brant, W. Opdyke, and D. Roberts,Refactoring: Improving the Design of Existing Code.Addison-Wesley Professional, June 1999.

[19] T. Mens and P. V. Gorp, “A taxonomy of model transforma-tion,” Electronic Notes in Theorical Compututer Science, vol.152, pp. pp. 125–142, 2006.

[20] E. R. Gansner and S. C. North, “An open graph visualizationsystem and its applications,” Software - Practice and Experi-ence, vol. 30, pp. 1203–1233, 1999.

[21] J. Pilgrim, B. Vanhooff, I. Schulz-Gerlach, and Y. Berbers,“Constructing and visualizing transformation chains,” inECMDA-FA ’08: Proceedings of the 4th European conferenceon Model Driven Architecture. Springer-Verlag, 2008, pp.17–32.

[22] R. Baeza-Yates and B. Ribeiro-Neto, Modern InformationRetrieval. Addison Wesley, May 1999.

[23] DOMINO, “DOMaINes et prOcessus methodologique.http://www.domino-rntl.org/.”

152