Model Refactoring and ATL Techniques

Model Refactoring and other Advanced
ATL Techniques

Frédéric Jouault (INRIA)
William Piers (Obeo)

© 2009 by INRIA, Obeo; made available under the EPL v1.0 | 23 March 2009

What You Will Learn in This Tutorial
• Refactoring models efficiently
• Compiling a DSL for SWTBot
• Visualizing models

2 Model Refactoring and other Advanced ATL Techniques | © 2009 by INRIA, Obeo; made available under the EPL v1.0

Discussion Topics
• About ATL
 ATL versions (2004 vs. 2006), notably refining mode
 Best Practices
 Model Transformation Virtual Machines
 ATL vs. QVT

• Around ATL
 M2M vs. M2T
 Where do models come from?
 Modeling platforms – AmmA
 Domain-Specific Languages and Modeling

 You can vote for the topics you are most interested in (2 or 3)
 You may suggest additional topics


Agenda
• Introduction
 Model-To-Model transformation in the MDE field
 M2M vs. M2T
• ATL Overview
• First exercise: Model Visualization
• Advanced Usage of ATL
• Second exercise: Model Refactoring
• Architecture
• Third exercise: A DSL Compiler for SWTBot
• ATL Industrialization
• Discussions


ATL - Description
• ATL : ATLAS Transformation Language
• ATL is a language and a virtual machine dedicated to
model transformation
• ATL is an Eclipse Model-to-Model (M2M) component,
inside of the Eclipse Modeling Project (EMP)


Definitions
• A model transformation is the automatic creation of target
models from source models.

• Applications*:
 Interoperability of Telephony Languages
 Modeling Web applications
 Converting graphics (e.g., Rational Rose to UML2 Tools)
 Measuring and verifying UML models
 etc.

Whatever your problem, you can write a lot of Java code or a
(generally) much simpler ATL transformation.

* Use cases available at: http://www.eclipse.org/m2m/atl/usecases/


Operational context: small theory
conformsTo Metametamodel
Class
Class
conformsTo conformsTo

MMa ATL MMb
Class Class Class
Green Rule Blue

Class Class

Red MMa2MMb.atl Pink
Rule Rule
conformsTo R2B G2P conformsTo

Ma Mb


Operational context of ATL
MOF
MMa is the MMB is the
source target
metamodel
MMa ATL MMb metamodel

MMa2MMb.atl
Ma Mb
Ma is the source model Mb is the target model


M2M vs. M2T
• M2M: Model To Model transformation
 Abstract syntax to abstract syntax
 Languages: ATL, QVT Operational, QVT Relations
• M2T: Model To Text transformation
 Abstract syntax to concrete syntax
 Languages: JET, xPand
• TMF: Textual Modeling Framework
 Abstract syntax to and from concrete syntax
 Languages: TCS, xText
• This tutorial is focused on M2M


Agenda
• Introduction
• ATL Overview
 Available resources: wiki, zoo, newsgroup, use cases,
etc.
 ATL language description
• Architecture
• Discussions


ATL history
• 1990 : first works on model transformation
• 1998 : initial publication for a Ph.D. thesis at the
University of Nantes
• 1998 - 2004 : Implementation
 CARROLL/MOTOR project (CEA, Thales, INRIA)
 Collaborative projects : ModelWare, ModelPlex, OpenEmbeDD
• 2004 : Eclipse GMT integration
• 2006 : Industrial solution inside of the Eclipse M2M
project


ATL community
• Active community
 Newsgroup: news://news.eclipse.org/eclipse.modeling.m2m
 Wiki: http://wiki.eclipse.org/ATL
 Bugzilla
 Use cases: http://www.eclipse.org/m2m/atl/usecases/
 Transformations zoo (i.e., a library):
http://www.eclipse.org/m2m/atl/atlTransformations/

• Other links
 Project page: http://www.eclipse.org/m2m/atl/


ATL documentation
• For a long time, ATL doc was dispatched over several
places
 ATL User Manual, out of date
 ATL wiki, disorganized
 Some information in newsgroup, mailing lists...

• Now merged into ATL wiki
http://wiki.eclipse.org/ATL/User_Guide
• Use of Mylyn Wikitext tool to generate Eclipse Help
• Eclipse Help produces a portable, printable,
searchable documentation support


ATL documentation

Mylyn WikiText
Eclipse Wiki extraction to
collaborative Eclipse Help
edition


ATL overview
• Source models and target models are distinct:
 Source models are read-only (they can only be navigated,
not modified),
 Target models are write-only (they cannot be navigated).
• The language is a declarative-imperative hybrid:
 Declarative part:
 Matched rules with automatic traceability support,
 Side-effect free navigation (and query) language: OCL 2.0
 Imperative part:
 Called rules,
 Action blocks.
• Recommended programming style: declarative


ATL overview (continued)
• A declarative rule specifies:
 a source pattern to be matched in the source models,
 a target pattern to be created in the target models for each
match during rule application.
• An imperative rule is basically a procedure:
 It is called by its name,
 It may take arguments,
 It can contain:
 A declarative target pattern,
 An action block (i.e. a sequence of statements),
 Both.


ATL overview (continued)
• Applying a declarative rule means:
 Creating the specified target elements,
 Initializing the properties of the newly created elements.
• There are three types of declarative rules:
 Standard rules that are applied once for each match,
 A given set of elements may only be matched by one standard
rule,
 Lazy rules that are applied as many times for each match as
it is referred to from other rules (possibly never for some
matches),
 Unique lazy rules that are applied at most once for each
match and only if it is referred to from other rules.


Declarative rules: source pattern
• The source pattern is composed of:
 A labeled set of types coming from the source metamodels,
 A guard (Boolean expression) used to filter matches .
• A match corresponds to a set of elements coming
from the source models that:
 Are of the types specified in the source pattern (one element
for each type),
 Satisfy the guard.


Declarative rules: target pattern
• The target pattern is composed of:
 A labeled set of types coming from the target metamodels,
 For each element of this set, a set of bindings.
 A binding specifies the initialization of a property of a target
element using an expression.
• For each match, the target pattern is applied:
 Elements are created in the target models (one for each type of
the target pattern),
 Target elements are initialized by executing the bindings:
 First evaluating their value,
 Then assigning this value to the corresponding property.


Execution order of declarative rules
• Declarative ATL frees the developer from specifying
execution order:
 The order in which rules are matched and applied is not
specified.
 Remark: the match of a lazy or unique lazy rules must be
referred to before the rule is applied.
 The order in which bindings are applied is not specified.
• The execution of declarative rules can however be
kept deterministic:
 The execution of a rule cannot change source models
 It cannot change a match,
 Target elements are not navigable
 The execution of a binding cannot change the value of
another.


Example: ClassDiagram to Relational – Overview
• The source metamodel ClassDiagram is a
simplification of class diagrams.
• The target metamodel Relational is a simplification of
the relational model.
 ATL declaration of the transformation:
module ClassDiagram2Relational;
create Mout : Relational from Min : ClassDiagram;

• The transformation excerpts used in this presentation
come from:
http://www.eclipse.org/m2m/atl/atlTransformations/#Class2Relational


Source Metamodel: ClassDiagram
NamedElement

+name : String

Classifier

+type

DataType Class +attr Attribute

+multivalued : Boolean
owner *
{ordered }

Target Metamodel: Relational

Named
+name:String

Table + col Column * + type Type

+ owner *
{ ordered }

+ keyOf 0..1 + key *


Sample Source and Target Models

Class2Table
SingleValuedAttribute2Column
MultiValuedAttribute2Column

ClassDiagram2Relational.atl – overview
NamedElement

+name : String
Class2Table
SingleValuedAttribute2Column
MultiValuedAttribute2Column
Classifier

+type

Named

DataType Class Attribute
+name:String
+attr
+multivalued : Boolean
owner *
{ ordered }

Table + col Column * + type Type

+ owner *
{ordered }

+ keyOf 0..1 + key *


ClassDiagram2Relational.atl – overview
• Informal description of rules
 Class2Table:
 A table is created from each class,
 The columns of the table correspond to the single-valued
attributes of the class,
 A column corresponding to the key of the table is created.
 SingleValuedAttribute2Column:
 A column is created from each single-valued attribute.
 MultiValuedAttribute2Column:
 A table with two columns is created from each multi-valued
attribute,
 One column refers to the key of the table created from the
owner class of the attribute,
 The second column contains the value of the attribute.


Rule Class2Table (1 Of 4)
• For each Class, create a Table :

rule Class2Table {
from -- source pattern
c : ClassDiagram!Class
to -- target pattern
t : Relational!Table
}


• The name of the Table is the name of the Class:

rule Class2Table {
from
to
t : Relational!Table (
name <- c.name -- a simple binding
)
}


• The columns of the table correspond to the single-valued
attributes of the class:
rule Class2Table {
from
to
name <- c.name,
col <- c.attr->select(e | -- a binding
not e.multiValued -- using complex
) -- navigation
)
}
• Remark: attributes are automatically resolved into columns by
automatic traceability support.

• Each Table owns a key containing a unique identifier:
rule Class2Table {
from
to
name <- c.name,
col <- c.attr->select(e | not e.multiValued
)->union(Sequence {key}),
key <- Set {key}
),
key : Relational!Column ( -- another target
name <- ‘Id’ -- pattern element
) -- for the key
30 }
Model Refactoring and other Advanced ATL Techniques | © 2009 by INRIA, Obeo; made available under the EPL v1.0

Rule SingleValuedAttribute2Column
• For each single-valued Attribute create a Column:

rule SingleValuedAttribute2Column {
from -- the guard is used for selection
a : ClassDiagram!Attribute (not a.multiValued)
to
c : Relational!Column (
name <- a.name
)
}


Rule MultiValuedAttribute2Column
• For each multi-valued Attribute create a Table, which contains
two columns:
 The identifier of the table created from the class owner of the
Attribute
 The value.
rule MultiValuedAttribute2Column {
id : Relational!Column (
from
a : ClassDiagram!Attribute (a.multiValued) name <- ‘Id’
to ),
t : Relational!Table ( value : Relational!Column (
name <- a.owner.name + ‘_’ + a.name, name <- a.name
col <- Sequence {id, value} )
), }


Object Constraint Language (OCL)
• Originally intended to express constraints over UML
models, for instance:
context Person inv: self.age > 0
• Extended to query any model
• Used in several transformation languages (e.g., ATL,
QVT) to compute values from the source models
• Specification:
 The version on which ATL is based is available from:
http://www.omg.org/docs/ptc/03-10-14.pdf
 Section 7: language overview
 Section 11: standard library
 Section 11.8: iterator expressions


ATL/OCL types hierarchy


Running ATL/OCL Queries Within Eclipse
• Considering a given OCL expression, such as:
5 mod 2
• Place it in an ATL query, for instance in file TestQuery.atl:
query TestQuery = (5 mod 2).debug('Result');
• Where the call to OclAny.debug(String) : OclAny:
 Does not change the result (it returns the value on which it is called)
 Prints the result on the console
 This operation may be called anywhere (e.g., to print intermediate
values)
• Advantages:
 May query any model
 May use debugger
• Drawbacks:
 Cannot specify a context


Iterator Expressions Returning Collections
• collect
Query: Sequence {1, 2, 3, 4}->collect(e | e + 2)
Result: Sequence {3, 4, 5, 6}
• reject
Query: Sequence {1, 2, 3, 4}->reject(e | e > 2)
Result: Sequence {1, 2}
• select
Query: Sequence {1, 2, 3, 4}->select(e | e > 2)
Result: Sequence {3, 4}
• sortedBy
Query: Sequence {3, 4, 1, 2}->sortedBy(e | e)
Result: Sequence {1, 2, 3, 4}


Predicate Iterator Expressions Admitting Multiple Iterators

• exists

Sequence {1, 2, 3, 4}->exists(e | true
e > 2)
Sequence
• forAll {1, 2, 3, 4}->exists(e | fals
e < 1) e
Sequence {1, 2, 3, 4}->exists(e, | true
Sequence {1, 2, 3, 4}->forAll(e false
f |> 2) f + 3)
e e=
Sequence {1, 2, 3, 4}->forAll(e | true
e > 0)

Other Iterator Expressions with One Iterator
• any
Query: Set{1, 2, 3, 4}->any(e | e > 2)
Result: 3
Query: Set{1, 2, 3, 4}->any(e | e > 2)
Result: 4
• isUnique
Query: Sequence {1, 2, 3, 4}->isUnique(e | e mod 2 = 1)
Result: false (Sequence {1, 0, 1, 0} contains duplicates)
Query: Sequence {1, 2, 3, 4}->isUnique(e | e)
Result: true
• one
Query: Set{1, 2, 3, 4}->one(e | e > 2)
Result: false

Iterate Expression
• Enables computation of any value from a collection
• Example:
Sequence {'one', 'two', 'three'}->iterate(e; acc : String = '(' |
acc + if acc = '(' then '' else ', 'endif + e
) + ')'
Result: '(one, two, three)'
• Description:
 The accumulator is initialized
 For each element in the source:
 The iterator gets the value of this element
 The body is evaluated
 The accumulator receives the resulting value
 The result is the value of the accumulator at the end of the
iteration

ATL editor


ATL content assist
• ADT (ATL Development Tools) has recently been
improved with basic content assist
 Type completion
 Left-side bindings completion
 Basic code templates


ATL Launch Configuration


Launching ATL using ANT
• Historically provided by GMT/AM3

• A new set of tasks is directly available into ATL 3.0
 Very close to the old AM3 tasks
 am3.saveModel => atl.saveModel
 am3.loadModel => atl.loadModel
 am3.atl => atl.launch
 Allows to specify transformation launching with more
parameters
 Specific Injector/Extractor

• Provide a way to chain transformations


Launching ATL using ANT
<project name="ClassDiagram2Relational" default="main">
<property name="source" value="ClassDiagram/Sample-ClassDiagram.xmi"/>
<property name="target" value="Relational/Sample-Relational.xmi"/>

<target name="main" depends="loadMetamodels">
<atl.loadModel modelHandler="EMF"
name="myClassDiagram" metamodel="ClassDiagram"
path="${source}"/>

<atl.launch path="ATLFiles/ClassDiagram2Relational.atl">
<inModel name="ClassDiagram" model="ClassDiagram"/>
<inModel name="IN" model="myClassDiagram"/>
<inModel name="Relational" model="Relational"/>
<outModel name="OUT" model="myRelational" metamodel="Relational"/>
</atl.launch>

<atl.saveModel model="myRelational" path="${target}"/>
</target>

<target name="loadMetamodels">
name="ClassDiagram" metamodel="%EMF"
path="ClassDiagram/ClassDiagram.ecore"/>
name="Relational" metamodel="%EMF"
path="Relational/Relational.ecore" />
</target>
</project>


Agenda
• Introduction
• ATL Overview
• Architecture
• Discussions


First exercise: Model Visualization
• Context
 UML models (but general approach)

• Objective
 provide a different way to visualize models
 applications in reverse engineering cartography

• A visualization tool: prefuse (http://prefuse.org/)
 Advanced / dynamic visualizations
 BSD license
 Accepts many data formats as input
 GraphML
 TreeML


First exercise: Model Visualization
• Overview:
UML Model Prefuse visualization


Agenda
• Introduction
• ATL Overview
• Simple and Efficient Refactoring Transformations
• Model Enrichment
• Architecture
• Discussions


Writing Interpreters in ATL
• An ATL interpreter typically evaluates a model into a
value.
 Example: simple expressions.

• Evaluation may involve input data that is not part of the
model:
 Example: XPath expressions evaluates over an XML model.

• The interpreter may be part of a larger transformation.

• How to write an evaluator:
 Define an evaluation helper on each metamodel class to
evaluate.


Example: Metamodel for Simple Expressions
Expression

+right

+left

IntegerExp OperatorExp
+value : Integer +operator : String


ATL Interpreter for Simple Expressions
query CalcEval =
let root : Calc!Expression.allInstances()->any(e | -- select root
e.refImmediateComposite().oclIsUndefined()) in
root.eval().debug('Result'); -- evaluate

helper context Calc!IntegerExp def: eval() : Integer =
self.value;

helper context Calc!OperatorExp def: eval() : Integer =
if self.operator = '+' then
self.left.eval() + self.right.eval()
else if self.operator = '*' then
self.left.eval() * self.right.eval()
else
self.operator.debug('UnsupportedOperator')
endif endif;

Simple Expressions in Java (1 Of 3)
abstract class Expression {
public abstract int eval();
}

class IntegerExp extends Expression {
int value;
public IntegerExp(int value) {
this.value = value;
}
public int eval() {
return value;
}
}


class OperatorExp extends Expression {
Expression left; String operator; Expression right;
public OperatorExp(Expression left, String operator, Expression right) {
this.left = left;
this.operator = operator;
this.right = right;
}
public int eval() {
int ret = 0;
if("+".equals(operator)) {
ret = left.eval() + right.eval();
} else if("*".equals(operator)) {
ret = left.eval() * right.eval();
} else {
System.err.println("Unsupported operator: " + operator);
System.exit(1);
}
return ret;
}
}


public class TestExpression {
public static void main(String args[]) {
System.out.println( // evaluating 1 + 4 * 3
new OperatorExp(
new IntegerExp(1),
"+",
new OperatorExp(
new IntegerExp(4),
"*",
new IntegerExp(3)
)
).eval()
);
}
}

Writing Serializers in ATL
• A serializer transforms a source model into a String.

• It is a special kind of interpreter that evaluates into a
String representing the evaluated model.

• Pros:
 Any string may be computed (e.g., XML, HTML).
 Easily usable from within a transformation (e.g., when parts of
the source model correspond to strings in the target model).

• Cons:
 A TCS syntax specification can already be used for
serialization.
 Some complex syntactic rules (e.g., proper parenthesizing of
expressions) are hard to represent (but TCS does it
55
automatically).

Example: ATL Serializer for Simple Expressions
query CalcEval =
let root : Calc!Expression.allInstances()->any(e | -- select root
e.refImmediateComposite().oclIsUndefined()) in
root.serialize().debug('Result'); -- serialize

helper context Calc!IntegerExp def: serialize() : String =
self.value.toString();

helper context Calc!OperatorExp def: serialize() : String =
'(' +
self.left.serialize() + ' ' +
self.operator + ' ' +
self.right.serialize() +
')';

Simple copy
-- Source metamodel: MMA -- Target metamodel: MMB
class A1 { class B1 {
attribute v1 : String; attribute v1 : String;
} }
module MMAtoMMB;
create OUT : MMB from IN : MMA;
rule A1toB1 {
from
s : MMA!A1
to
t : MMB!B1 (
v1 <- s.v1,
v2 <- s.v2
)
}

Structure creation
class A1 { class B1 { reference b2 : B2;
attribute v1 : String; reference b3 : B3; }
attribute v2 : String; class B2 { attribute v1 : String; }
} class B3 { attribute v2 : String; }
module MMAtoMMB; t2 : MMB!B2 (
create OUT : MMB from IN : MMA; v1 <- s.v1
rule A1toB1andB2andB3 { ),
from t3 : MMB!B3 (
s : MMA!A1 v2 <- s.v2
to )
t1 : MMB!B1 ( }
b2 <- t2,
b3 <- t3
),

Structure simplification
class A1 { reference a2 : A2; class B1 {
reference a3 : A3; } attribute v1 : String;
class A2 { attribute v1 : String; } attribute v2 : String;
class A3 { attribute v2 : String; } }
module MMAtoMMB;
rule A1toB1 {
from
s : MMA!A1
to
t : MMB!B1 (
v1 <- s.a2.v1,
v2 <- s.a3.v2
)
}

Structure simplification (needlessly more complex)
class A1 { reference a2 : A2; class B1 {
reference a3 : A3; } attribute v1 : String;
class A2 { attribute v1 : String; } attribute v2 : String;
class A3 { attribute v2 : String; } }
module MMAtoMMB;
rule A1toB1 {
from s1 : MMA!A1, s2 : MMA!A2,
s3 : MMA!A3 (s1.a2 = s2 and s1.a3 = s3)
to
t : MMB!B1 (
v1 <- s.a2.v1,
v2 <- s.a3.v2
)
}

Traceability: implicit resolution of default elements
class A1 { reference a2 : A2; class B1 { reference b2 : B2;
reference a3 : A3; } reference b3 : B3; }
class A2 { attribute v1 : String; } class B2 { attribute v1 : String; }
module MMAtoMMB; rule A2toB2 {
create OUT : MMB from IN : MMA; from s : MMA!A2
rule A1toB1 { to t : MMB!B2 (
from v1 <- s.v1 )
s : MMA!A1 }
to rule A3toB3 {
t : MMB!B1 ( from s : MMA!A3
b2 <- s.a2, -- HERE to t : MMB!B3 (
b3 <- s.a3 -- HERE v2 <- s.v2 )
) }
}

Remark: same result, less modular
class A1 { reference a2 : A2; class B1 { reference b2 : B2;
reference a3 : A3; } reference b3 : B3; }
create OUT : MMB from IN : MMA; v1 <- s.a2.v1
rule A1toB1 { ),
from t3 : MMB!B3 (
s : MMA!A1 v2 <- s.a3.v2
to )
t1 : MMB!B1 ( }
b2 <- t2,
b3 <- t3
),

Traceability: resolveTemp for additional elements
class A1 { reference a2 : A2; } class B1 { reference b2 : B2;
class A2 { attribute v1 : String; reference b3 : B3; }
attribute v2 : String; } class B2 { attribute v1 : String; }
class B3 { attribute v2 : String; }
module MMAtoMMB; rule A2toB2andB3 {
create OUT : MMB from IN : MMA; from
rule A1toB1 { s : MMA!A2
from s : MMA!A1 to
to t1 : MMB!B2 (
t : MMB!B1 ( v1 <- s.v1
b2 <- s.a2, ),
b3 <- t2 : MMB!B3 (
thisModule.resolveTemp(s.a2, 't2') v2 <- s.v2
) )
}
63 }

Traceability: resolveTemp even for first element
class A1 { reference a2 : A2; } class B1 { reference b2 : B2;
class A2 { attribute v1 : String; reference b3 : B3; }
attribute v2 : String; } class B2 { attribute v1 : String; }
class B3 { attribute v2 : String; }
module MMAtoMMB; rule A2toB2andB3 {
from s : MMA!A1 to
to t : MMB!B1 ( t1 : MMB!B2 (
b2 <- -- possible but complex v1 <- s.v1
thisModule.resolveTemp(s.a2, 't1'), ),
b3 <- t2 : MMB!B3 (
thisModule.resolveTemp(s.a2, 't2') v2 <- s.v2
) )
}
64 }

Structure creation revisited with resolveTemp
class A1 { class B1 { reference b2 : B2;
attribute v1 : String; reference b3 : B3; }
attribute v2 : String; class B2 { attribute v1 : String; }
} class B3 { attribute v2 : String; }
create OUT : MMB from IN : MMA; v1 <- s.v1
rule A1toB1andB2andB3 { ),
from t3 : MMB!B3 (
s : MMA!A1 v2 <- s.v2
to )
t1 : MMB!B1 (-- possible but complex }
b2 <- thisModule.resolveTemp(s, 't2'),
b3 <- thisModule.resolveTemp(s, 't3')
),

Kinds of matched (declarative) rules
• We have only seen standard rules in default mode so far.
Kind of Number of Number of Kind of
rule references times the traceability
to source target pattern link
pattern gets created created
standard 0 1 default or
1 1 not (using
keyword
n>1 1
nodefault)
unique
66
0 0 Not default

Syntax of the different kinds of matched rules
Kind of rule Definition Reference
standard rule R1 { <value of type
default from s : MMA!A1>
MMA!A1 or
to t : MMB! <collection of
B1 } MMA!A1>
standard nodefault rule not currently
nodefault R1 { possible
(1) For collections: aCollection->collect(e | thisModule.R1(e))
from s :
67
MMA!A1

Rule inheritance
• Rule inheritance, to help structure transformations
and reuse rules and patterns:
 A child rule matches a subset of what its parent rule
matches,
 All the bindings of the parent still make sense for the child,
 A child rule specializes target elements of its parent rule:
 Initialization of existing elements may be improved or changed,
 New elements may be created,
 Syntax:
abstract rule R1 {
-- ...
}
rule R2 extends R1 {
-- ...
}

Copy class inheritance without rule inheritance
class A2 extends A1 { class B2 extends B1 {
} }
module MMAtoMMB; rule A2toB2 {
from to
s : MMA!A1 t : MMB!B2 (
to v1 <- s.v1,
t : MMB!B1 ( v2 <- s.v2
v1 <- s.v1 )
) }
}

Copy class inheritance with rule inheritance
class A2 extends A1 { class B2 extends B1 {
} }
module MMAtoMMB; rule A2toB2 extends A1toB1 {
from to
s : MMA!A1 t : MMB!B2 (
to -- v1 <- s.v1,
t : MMB!B1 ( v2 <- s.v2
v1 <- s.v1 )
) }
}

Guidelines
Make your transformation as complex as necessary but
as simple as possible.

• Prefer declarative over imperative: only use imperative
for the part of a transformation that needs it if it even
does.

• Prefer simpler constructs over more complex ones:
 Use standard rules when possible, otherwise use unique lazy
rules, and use lazy rules only if necessary.
 Only use resolveTemp if necessary.
 Prefer iterators (e.g., select, collect) over iterate.


Refactoring Transformations – Example

• Public2Private:
 Making every public Property private
 Leaving the rest of the model unchanged

• Note: although this example uses UML, the approach
presented here is metamodel-independent.


Operational context of ATL (Reminder)
MOF
MMa is the MMB is the
source target
metamodel
MMa ATL MMb metamodel

MMa2MMb.atl
Ma Mb
Ma is the source model Mb is the target model
(read-only) (write-only)

Refactoring transformations – Overview
• General characteristics:
 Operate on a single metamodel (i.e., MMa = MMb)
 Most of the model remains unchanged (i.e., Ma ≈ Mb)

• Optional characteristics:
 May apply to only a given part of the model (i.e., a selection)
 Identity of elements may need to be preserved (e.g., in an
editor, although usually not necessary if XMI-to-XMI)

• Challenges:
 Modification of an existing model (i.e., different from the
general scheme)
 Possible interactive usage (requires a certain performance
level)


Implementation of Refactoring Transformations
• Writing every rule
 Simple, but not scalable: typically about one rule per metamodel
element (e.g., 4153 lines of code for UML)
• Modifying a generated copy transformation
 Scales easily to a large number of metamodel elements, but
important information is hidden
• Superimposing a few rules on a copy transformation
 Relatively elegant: the generated copy transformation is left
untouched, refactoring rules are grouped into a separate module

• Common issue of these approaches: they copy the source model
elements into a different target model
 Performance is not especially good, they do not scale to large
models
 Identity of elements is not preserved for use within an editor


UML Public2Private – Superimposition
module Public2Private;
Technique
create OUT : UML2 from IN : UML2;

rule Property {
from rule Property {
from
s : UML2!Property (
s.visibility = #public

to
)
s : UML2!Property (
t : UML2!Property (
visibility <- #private,
s.visibility = #public
name <- s.name, )
to
isLeaf <- s.isLeaf,
isStatic <- s.isStatic,
isOrdered <- s.isOrdered,
isUnique <- s.isUnique, t : UML2!Property (
isReadOnly <- s.isReadOnly,
isDerived <- s.isDerived,
visibility <- #private,
isDerivedUnion <- s.isDerivedUnion,
aggregation <- s.aggregation,
name <- s.name,
eAnnotations <- s.eAnnotations, isLeaf <- s.isLeaf,
…
ownedComment <- s.ownedComment,
clientDependency <- s.clientDependency,
nameExpression <- s.nameExpression,
type <- s.type,
upperValue <- s.upperValue,
lowerValue <- s.lowerValue,
templateParameter <- s.templateParameter,
end <- s.end,
deployment <- s.deployment,
templateBinding <- s.templateBinding, Superimposed on
ownedTemplateSignature <- s.ownedTemplateSignature,
redefinedProperty <- s.redefinedProperty, UML2Copy.atl
defaultValue <- s.defaultValue,
subsettedProperty <- s.subsettedProperty, (4153 generated lines)
association <- s.association,
qualifier <- s.qualifier

}
76 )

ATL Refining Mode
• Challenges:
 Keeping as much as possible of ATL semantics
 Performance suitable for interactive usage
 Preservation of elements identity

• ATL 2004 refining mode:
 Works as the approaches presented earlier: by copying
source model elements to target model
 Only rules that do not perform simple copy need to be
specified, with all bindings (similar to superimposition but with
an implicit copy transformation)
 Keeps ATL semantics, but neither very performant, nor
identity preserving


ATL 2006 Refining Mode

• Works by performing in-place transformation
Still keeps ATL semantics
(i.e., write-only target model during rule execution)
 Performs well-enough for interactive usage (see
demo)
 Preserves elements identity

• Only rules and bindings that do perform
changes need to be specified
 Less verbose than previous techniques (including
ATL 2004)


Public2Private in ATL 2006 Refining Mode

create OUT : UML refining IN : UML;
rule Property {
from
s : UML!Property (s.visibility = #public)
to
t : UML!Property (
visibility <- #private
)
}

What would happen in Standard Mode?

create OUT : UML from IN : UML;
rule Property {
from
s : UML!Property (s.visibility = #public)
to
t : UML!Property (
visibility <- #private
)
}

Public2Private.atl on j2se-1_2-api.uml (6.17MiB)

Time (s)
Bytecod Lines of
Transformat Tota es code
ion l
Superimposi
tion 2467779
209 216 41
7

Refining 3.20 11 354364 15
2.7
81 Ratio 65.3 19.6 69.6

Public2Private.atl on j2se-1_6-api.uml (13.14MiB)

Time (s)
Bytecod Lines of
Transformat Tota es code
ion l
Superimposi
tion 5247898
496 515 41
4

Refining 5.75 25 674874 15
2.7
82 Ratio 86.3 20.6 77.8

Public2Private plus Accessors

rule Property {
from
s : UML!Property (
s.visibility = #public)
to
t : UML!Property (
visibility <- #private ),
getter : UML!Operation (
namespace <- s.namespace, -- ! see later
name <- 'get' + s.name.firstToUpper,
ownedParameter <- getterReturnParam ),
getterReturnParam : UML!Parameter (
name <- 'return',
direction <- #return,
type <- s.type )
} …

ATL 2006 Refining Mode – Implementation
Overview
• Computing changes
 No change to the source model during rule execution, which
happens as with a read-only source model
 All changes are stored in a RefiningTrace model

• Applying changes
 After the execution of all rules

• The trace:
 may be serialized
 could be serialized and not applied (e.g., to use a different
application engine)


Public2Private plus Accessors –
Changeability Issue

rule Property {
from
s : UML!Property (
to
t : UML!Property (
getter : UML!Operation (
namespace <- s.namespace,
name <- 'return',
type <- s.type )
} …

Public2Private plus Accessors –
Introducing Reverse Bindings

rule Property {
from
s : UML!Property (
to
t : UML!Property (
getter : UML!Operation ->
(s.namespace.ownedOperation) (
name <- 'return',
type <- s.type )
} …

Launching ATL 2006 Refining Transformations
• Adding inout models to the ATL Ant Task
<atl.launch path="${base.path}/Public2Private.atl">
<inoutModel name="IN" model="source"/>
<outModel name="refiningTrace"
metamodel="RefiningTrace" model="refiningTrace"/>
</atl.launch>

• The user still sees different source and target models, but there
are effectively the same

• There are two other ways to launch a refining transformation:
 Using the launch configuration (see next slide)
 Programmatically (e.g., from Eclipse plugins as shown in next exercise)


ATL 2006 Refining Launch Configuration


Model Enrichment
• Problem
 Adding information from model mB into model mA in order to obtain
enriched model mA’

• Approach
 Write a transformation refining mA and taking mB as additional
source model
create mA’ : MMA refining mA : MMA, mB : MMB;

• Example:
 Annotating EDataTypes from an Ecore metamodel with
instanceClassNames
module ApplyAnnotations2Ecore;
create OUT : Ecore refining IN : Ecore, annotations : Annotation;


Model Enrichment Example
-- @atlcompiler atlworkspace
-- @nsURI Ecore=http://www.eclipse.org/emf/2002/Ecore
module ApplyAnnotations2Ecore;
create OUT : Ecore refining IN : Ecore, annotations : Annotation;
rule DataTypeAnnotations {
from
s : Ecore!EDataType
to
t : Ecore!EDataType (
instanceClassName <-
let a : String = s.getAnnotation('instanceClassName') in
if a.oclIsUndefined() then
s.instanceClassName
else
a
endif
)
}
-- getAnnotation helper not shown here
-- […]


Agenda
• Introduction
• ATL Overview
• Architecture
• Discussions


Second exercise: Model Refactoring
• Intent
 Provide in-place refactoring actions on models
 Big models support
 Reversible actions

• Realization: a refactoring pop-up menu
 Based on ATL refining mode
 Available on UML2 models (both with the tree editor and
UML2Tools)
 Set public fields to private
 Optionally adds getters and setters

Use-case: privatization of public attributes

Second exercise: Model Refactoring
• Example: refactoring on UML2Tools


Agenda
• Introduction
• ATL Overview
• Architecture
 Overview
 The new virtual machine: EMF-VM
• Discussions


ATL main plugins organization

Eclipse ui integration

Parser and Compiler
utilities
ATL Core API

ATL EMF–specific VM
ATL Regular VM


ATL Core API
• Problem
 ATL initial architecture changed many times, without strict
conventions
 Integration of several contributions
 Two Vms, two compilers
• Intent
 Need to reorganize ATL core to resolve maintenance and
accessibility issues
 Provide an unique and simple way to use ATL
programmatically
• Realization
 A Core API which manages models loading/saving and ATL
launching
 Provides extensibility at several levels


ATL Core API


ATL architecture
• Intermediate file format : ASM
• Modular VM dedicated to M2M
support
 A complete specification
describes the VM
(http://www.eclipse.org/m2m/atl/doc/)
 Can be implemented on different
platforms (Java, .Net)


ATL execution process
• 2 steps
 Compilation
 Execution


ATL Virtual Machine
• ATL core engine
• Byte code interpreter (ASM)
 Granular model management instruction
 Uses OCL/ATL type hierarchy
 Uses an abstract model handler layer
• ATL VM defined by a concrete specification
 Allows other language implementation
• ASM code
...
<operation name="122">
<context type="8"/>
<parameters>
</parameters>
<code>
<push arg="77"/>
<push arg="25"/>
<findme/>
<push arg="23"/>
...


EMF-VM
• A new ATL Virtual Machine is now available
 Increased performance
 EMF-only (no wrapping of EObjects)
• At this time...
 Some missing features (decreasing in number quickly):
•UML profile support
•Debugger interactions
• Non-regression evaluated with a new test plugin


Non-regression tests
• Non-regression engine uses EMF Compare to check
output models conformance

• Non-regression tests also allows to check

ATL Regular VM

ATL Compiler

ATL Parser

• Provides a way for users to safely work on base
components: bug corrections, new features


Non regression wiki page


EMF-VM Benchmarks


Agenda
• Introduction
• ATL Overview
• Architecture
• Discussions


Third Exercise: A DSL Compiler for SWTBot
Intent
 Provide a simpler syntax for SWTBot (i.e., a
Domain-Specific Language or DSL)
 Generate Java code from simpler syntax

Prerequisites
 SWTBot DSL implementation (metamodel, syntax)
 SimpleJava metamodel (only what is necessary for
generation of SWTBot code)

Realization
 An ATL transformation from SWTBot to SimpleJava


Third Exercise: A DSL Compiler for SWTBot


Agenda
• Introduction
• ATL Overview
• Architecture
• Discussions


ATL Industrialization process
idea

Labo

experimentation industrialization

Users PME
validation commercialization
partnership


Roadmap
• Roadmap overview:
 Industrialization
 EMF-VM improvements
 Stabilization
 Internationalization
 Improve Eclipse integration
 New features
 Packaging
 Incremental transformation support
• Means:
 Existing features amelioration (IDE)
 Complex features research (incremental)


ATL Releng module


Done
• API refactoring
 Correction of current issues
 Provide a “clean” Java access to ATL for developers
• ATL ant tasks
• Documentation
 Merging wiki / pdf
 doc plugin synchronization
• Many bugs corrections & feature improvements
 Loading an UML2 profile from a plugin
 Stable EMF ResourceSet management strategy
• Examples: public2private
 Provide launch configuration, ant file and java popup samples


What’s next?
• IDE improvements
 Content assist
 Syntax colors
 File wizard
 Launch configurations
 Integration of a CS contribution: ATL profiler
• Debugger
 Reimplemented for at least EMFVM
• Documentation improvement


Agenda
• Introduction
• ATL Overview
• Architecture
• Discussions


Discussion Topics
• About ATL
 ATL versions (2004 vs. 2006), notably refining mode
 Best Practices
 Model Transformation Virtual Machines
 ATL vs. QVT

• Around ATL
 M2M vs. M2T
 Where do models come from?
 Modeling platforms – AmmA
 Domain-Specific Languages and Modeling

 You can vote for the topics you are most interested in (2 or 3)
 You may suggest additional topics


Legal Notices
• Java and all Java-based trademarks are trademarks of
Sun Microsystems, Inc. in the United States, other
countries, or both
• Other company, product, or service names may be
trademarks or service marks of others


END
• Questions or Comments?


Model Refactoring and ATL Techniques

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Model Refactoring and ATL Techniques

Similar to Model Refactoring and ATL Techniques (20)

Recently uploaded

Recently uploaded (20)

Model Refactoring and ATL Techniques