atl tutorial - eclipsecon 2009

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

Model Refactoring and other Advanced ATL Techniques

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

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

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


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 LanguageATLAS 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/

http://www.eclipse.org/m2m/atl/usecases/


Operational context: small theory

G 2 P

RuleR 2 B

Rule

Ma Mb

MMaGreen

Class

RedClass

MMbBlueClass

PinkClass

Metametamodel

ClassClass

ATL

RuleClass

MMa2MMb.atl

conformsTo conformsTo

conformsTo conformsTo

conformsTo


Operational context of ATL

MOF

MMa MMb

Ma MbMMa2MMb.atl

ATLMMa is thesourcemetamodel

Ma is the source model Mb is the target model

MMB is thetargetmetamodel


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• First exercise: Model Visualization• Advanced Usage of ATL• Second exercise: Model Refactoring• Architecture• Third exercise: A DSL Compiler for SWTBot• ATL Industrialization• 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/

http://wiki.eclipse.org/ATL



http://www.eclipse.org/m2m/atl/usecases/



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 wikihttp://wiki.eclipse.org/ATL/User_Guide

• Use of Mylyn Wikitext tool to generate Eclipse Help• Eclipse Help produces a portable, printable, searchable documentation support

http://wiki.eclipse.org/ATL/User_Guide

http://wiki.eclipse.org/ATL/User_Guide


ATL documentation

Eclipse Wiki collaborative edition

Mylyn WikiText extraction to Eclipse Help


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

Attribute +multivalued : Boolean

+type

DataType Class

+attr

* { ordered }

owner


Target Metamodel: Relational

Named + name : String

Table Column

owner +

col +

* { ordered }

keyOf + 0..1 key + *

Type * type +


Sample Source and Target Models

Class2TableSingleValuedAttribute2ColumnMultiValuedAttribute2Column


ClassDiagram2Relational.atl – overview

NamedElement +name : String

Classifier

Attribute +multivalued : Boolean

+type

DataType Class

+attr

* { ordered }

owner

Named + name : String

Table Column

owner +

col + *

{ ordered } keyOf + 0..1 key + *

Type * type +

Class2TableSingleValuedAttribute2ColumnMultiValuedAttribute2Column


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!Classto -- target pattern

t : Relational!Table}


Rule Class2Table (2 Of 4)• The name of the Table is the name of the Class:

rule Class2Table {from

c : ClassDiagram!Classto

t : Relational!Table (name <- c.name -- a simple binding

)}


Rule Class2Table (3 Of 4)• The columns of the table correspond to the single-valued

attributes of the class:rule Class2Table {

fromc : ClassDiagram!Class

tot : Relational!Table (

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.


Rule Class2Table (4 Of 4)• Each Table owns a key containing a unique identifier:rule Class2Table {

fromc : ClassDiagram!Class

tot : Relational!Table (

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

}


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 {from

a : ClassDiagram!Attribute (a.multiValued)to

t : Relational!Table (name <- a.owner.name + ‘_’ + a.name,col <- Sequence {id, value}

),

id : Relational!Column (name <- ‘Id’

),value : Relational!Column (

name <- a.name)

}


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

http://www.omg.org/docs/ptc/03-10-14.pdf


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}

• rejectQuery: Sequence {1, 2, 3, 4}->reject(e | e > 2)Result: Sequence {1, 2}

• selectQuery: Sequence {1, 2, 3, 4}->select(e | e > 2)Result: Sequence {3, 4}

• sortedByQuery: Sequence {3, 4, 1, 2}->sortedBy(e | e)Result: Sequence {1, 2, 3, 4}


Predicate Iterator Expressions Admitting Multiple Iterators

• exists

• forAll

Sequence {1, 2, 3, 4}->exists(e | e > 2)

true

Sequence {1, 2, 3, 4}->exists(e | e < 1)

false

Sequence {1, 2, 3, 4}->exists(e, f | e = f + 3)

trueSequence {1, 2, 3, 4}->forAll(e | e > 2)

false

Sequence {1, 2, 3, 4}->forAll(e | e > 0)

true

Sequence {1, 2, 3, 4}->forAll(e, f | e <> f)

false


• anyQuery: Set{1, 2, 3, 4}->any(e | e > 2)Result: 3Query: Set{1, 2, 3, 4}->any(e | e > 2)Result: 4

• isUniqueQuery: 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

• oneQuery: Set{1, 2, 3, 4}->one(e | e > 2)Result: false

Other Iterator Expressions with One Iterator


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.0Very 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 parametersSpecific 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"><atl.loadModel modelHandler="EMF"

name="ClassDiagram" metamodel="%EMF" path="ClassDiagram/ClassDiagram.ecore"/>

<atl.loadModel modelHandler="EMF" name="Relational" metamodel="%EMF" path="Relational/Relational.ecore" />

</target></project>


Agenda• Introduction• 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


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

GraphMLTreeML


First exercise: Model Visualization• Overview:

UML Model Prefuse visualization


Agenda• Introduction• ATL Overview• First exercise: Model Visualization• Advanced Usage of ATL

• Simple and Efficient Refactoring Transformations• Model Enrichment

• Second exercise: Model Refactoring• Architecture• Third exercise: A DSL Compiler for SWTBot• ATL Industrialization• 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

+value : IntegerIntegerExp

+operator : StringOperatorExp

+left

+right


ATL Interpreter for Simple Expressionsquery CalcEval =

let root : Calc!Expression.allInstances()->any(e | -- select roote.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;}

}


Simple Expressions in Java (2 Of 3)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;

}}


Simple Expressions in Java (3 Of 3)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 automatically).


Example: ATL Serializer for Simple Expressionsquery CalcEval =

let root : Calc!Expression.allInstances()->any(e | -- select roote.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: MMAclass A1 { attribute v1 : String; attribute v2 : String;}

-- Target metamodel: MMBclass B1 { attribute v1 : String; attribute v2 : 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-- Source metamodel: MMAclass A1 { attribute v1 : String; attribute v2 : String;}

-- Target metamodel: MMBclass B1 { reference b2 : B2; reference b3 : B3; }class B2 { attribute v1 : String; }class B3 { attribute v2 : String; }

module MMAtoMMB;create OUT : MMB from IN : MMA;rule A1toB1andB2andB3 { from s : MMA!A1 to t1 : MMB!B1 ( b2 <- t2, b3 <- t3 ),

t2 : MMB!B2 ( v1 <- s.v1 ), t3 : MMB!B3 ( v2 <- s.v2 )}


Structure simplification-- Source metamodel: MMAclass A1 { reference a2 : A2; reference a3 : A3; }class A2 { attribute v1 : String; }class A3 { attribute v2 : String; }


module MMAtoMMB;create OUT : MMB from IN : MMA;rule A1toB1 { from s : MMA!A1 to t : MMB!B1 ( v1 <- s.a2.v1, v2 <- s.a3.v2 )}


Structure simplification (needlessly more complex)-- Source metamodel: MMAclass A1 { reference a2 : A2; reference a3 : A3; }class A2 { attribute v1 : String; }class A3 { attribute v2 : String; }


module MMAtoMMB;create OUT : MMB from IN : MMA;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-- Source metamodel: MMAclass A1 { reference a2 : A2; reference a3 : A3; }class A2 { attribute v1 : String; }class A3 { attribute v2 : String; }


module MMAtoMMB;create OUT : MMB from IN : MMA;rule A1toB1 { from s : MMA!A1 to t : MMB!B1 ( b2 <- s.a2, -- HERE b3 <- s.a3 -- HERE )}

rule A2toB2 { from s : MMA!A2 to t : MMB!B2 ( v1 <- s.v1 )}rule A3toB3 { from s : MMA!A3 to t : MMB!B3 ( v2 <- s.v2 )}


Remark: same result, less modular-- Source metamodel: MMAclass A1 { reference a2 : A2; reference a3 : A3; }class A2 { attribute v1 : String; }class A3 { attribute v2 : String; }


module MMAtoMMB;create OUT : MMB from IN : MMA;rule A1toB1 { from s : MMA!A1 to t1 : MMB!B1 ( b2 <- t2, b3 <- t3 ),

t2 : MMB!B2 ( v1 <- s.a2.v1 ), t3 : MMB!B3 ( v2 <- s.a3.v2 )}


Traceability: resolveTemp for additional elements-- Source metamodel: MMAclass A1 { reference a2 : A2; }class A2 { attribute v1 : String; attribute v2 : String; }


module MMAtoMMB;create OUT : MMB from IN : MMA;rule A1toB1 { from s : MMA!A1 to t : MMB!B1 ( b2 <- s.a2, b3 <- thisModule.resolveTemp(s.a2, 't2') )}

rule A2toB2andB3 { from s : MMA!A2 to t1 : MMB!B2 ( v1 <- s.v1 ), t2 : MMB!B3 ( v2 <- s.v2 )}


Traceability: resolveTemp even for first element-- Source metamodel: MMAclass A1 { reference a2 : A2; }class A2 { attribute v1 : String; attribute v2 : String; }


module MMAtoMMB;create OUT : MMB from IN : MMA;rule A1toB1 { from s : MMA!A1 to t : MMB!B1 ( b2 <- -- possible but complex thisModule.resolveTemp(s.a2, 't1'), b3 <- thisModule.resolveTemp(s.a2, 't2') )}

rule A2toB2andB3 { from s : MMA!A2 to t1 : MMB!B2 ( v1 <- s.v1 ), t2 : MMB!B3 ( v2 <- s.v2 )}


Structure creation revisited with resolveTemp-- Source metamodel: MMAclass A1 { attribute v1 : String; attribute v2 : String;}


module MMAtoMMB;create OUT : MMB from IN : MMA;rule A1toB1andB2andB3 { from s : MMA!A1 to t1 : MMB!B1 (-- possible but complex b2 <- thisModule.resolveTemp(s, 't2'), b3 <- thisModule.resolveTemp(s, 't3') ),

t2 : MMB!B2 ( v1 <- s.v1 ), t3 : MMB!B3 ( v2 <- s.v2 )}


Kinds of matched (declarative) rules

• We have only seen standard rules in default mode so far.

Kind of rule

Number of references to source pattern

Number of times the target pattern gets created

Kind of traceability link created

standard 01

n > 1

111

default or not (using keyword

nodefault)

unique lazy

01

n > 1

011

Not default

lazy 01

n > 1

01n

Not default


(1) For collections: aCollection->collect(e | thisModule.R1(e))

Syntax of the different kinds of matched rulesKind of rule Definition Referencestandard default

rule R1 { from s : MMA!A1 to t : MMB!B1 }

<value of type MMA!A1>or<collection of MMA!A1>

standard nodefault

nodefault rule R1 { from s : MMA!A1 to t : MMB!B1 }

not currently possible

unique lazy unique lazy rule R1 { from s : MMA!A1 to t : MMB!B1 }

thisModule.R1(<value of type MMA!A1>)See (1)

lazy lazy rule R1 { from s : MMA!A1 to t : MMB!B1 }

thisModule.R1(<value of type MMA!A1>)See (1)


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

rule A2toB2 { from s : MMA!A2 to t : MMB!B2 ( v1 <- s.v1, v2 <- s.v2 )}

module MMAtoMMB;create OUT : MMB from IN : MMA;rule A1toB1 { from s : MMA!A1 to t : MMB!B1 ( v1 <- s.v1 )}

-- Target metamodel: MMBclass B1 { attribute v1 : String; }class B2 extends B1 { attribute v2 : String;}

-- Source metamodel: MMAclass A1 { attribute v1 : String; }class A2 extends A1 { attribute v2 : String;}


Copy class inheritance with rule inheritance

rule A2toB2 extends A1toB1 { from s : MMA!A2 to t : MMB!B2 ( -- v1 <- s.v1, v2 <- s.v2 )}

module MMAtoMMB;create OUT : MMB from IN : MMA;rule A1toB1 { from s : MMA!A1 to t : MMB!B1 ( v1 <- s.v1 )}

-- Target metamodel: MMBclass B1 { attribute v1 : String; }class B2 extends B1 { attribute v2 : String;}

-- Source metamodel: MMAclass A1 { attribute v1 : String; }class A2 extends A1 { attribute v2 : String;}


GuidelinesMake 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 MMb

Ma MbMMa2MMb.atl

ATLMMa is thesourcemetamodel

Ma is the source model(read-only)

Mb is the target model(write-only)

MMB is thetargetmetamodel


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 Techniquemodule Public2Private;

create OUT : UML2 from IN : UML2;

rule Property {from

s : UML2!Property (s.visibility = #public

)to

t : UML2!Property (visibility <- #private,name <- s.name,isLeaf <- s.isLeaf,isStatic <- s.isStatic,isOrdered <- s.isOrdered,isUnique <- s.isUnique,isReadOnly <- s.isReadOnly,isDerived <- s.isDerived,isDerivedUnion <- s.isDerivedUnion,aggregation <- s.aggregation,eAnnotations <- s.eAnnotations,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,ownedTemplateSignature <- s.ownedTemplateSignature,redefinedProperty <- s.redefinedProperty,defaultValue <- s.defaultValue,subsettedProperty <- s.subsettedProperty,association <- s.association,qualifier <- s.qualifier

)}

rule Property { from s : UML2!Property ( s.visibility = #public ) to t : UML2!Property ( visibility <- #private, name <- s.name, isLeaf <- s.isLeaf,…

Superimposed on UML2Copy.atl(4153 generated lines)


• 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 Refining Mode


•Works by performing in-place transformationStill 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)

ATL 2006 Refining Mode


Public2Private in ATL 2006 Refining Mode

module Public2Private;create OUT : UML refining IN : UML;rule Property {

froms : UML!Property (s.visibility = #public)

tot : UML!Property (

visibility <- #private)

}


module Public2Private;create OUT : UML from IN : UML;rule Property {

froms : UML!Property (s.visibility = #public)


visibility <- #private)

}

What would happen in Standard Mode?


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

Time (s)Bytecod

esLines of

codeTransformation

Total

Superimposition 209 216 2467779

7 41

Refining 3.20 11 354364 15

Ratio 65.3 19.6 69.62.7


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

Time (s)Bytecod

esLines of

codeTransformation

Total

Superimposition 496 515 5247898

4 41

Refining 5.75 25 674874 15

Ratio 86.3 20.6 77.82.7


Public2Private plus Accessors

rule Property {from

s : UML!Property (s.visibility = #public)


visibility <- #private ),getter : UML!Operation (

namespace <- s.namespace, -- ! see latername <- '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)


rule Property {from



visibility <- #private ),getter : UML!Operation (

namespace <- s.namespace,name <- 'get' + s.name.firstToUpper,ownedParameter <- getterReturnParam ),


} …

Public2Private plus Accessors – Changeability Issue


rule Property {from



visibility <- #private ),getter : UML!Operation ->

(s.namespace.ownedOperation) (name <- 'get' + s.name.firstToUpper,ownedParameter <- getterReturnParam ),


} …

Public2Private plus Accessors – Introducing Reverse Bindings


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 modelcreate mA’ : MMA refining mA : MMA, mB : MMB;

• Example: Annotating EDataTypes from an Ecore metamodel with

instanceClassNamesmodule ApplyAnnotations2Ecore;create OUT : Ecore refining IN : Ecore, annotations : Annotation;


Model Enrichment Example-- @atlcompiler atlworkspace-- @nsURI Ecore=http://www.eclipse.org/emf/2002/Ecoremodule ApplyAnnotations2Ecore;create OUT : Ecore refining IN : Ecore, annotations : Annotation;

rule DataTypeAnnotations {from

s : Ecore!EDataTypeto

t : Ecore!EDataType (instanceClassName <-

let a : String = s.getAnnotation('instanceClassName') inif a.oclIsUndefined() then

s.instanceClassNameelse

aendif

)}-- getAnnotation helper not shown here-- […]


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• First exercise: Model Visualization• Advanced Usage of ATL• Second exercise: Model Refactoring• Architecture

OverviewThe new virtual machine: EMF-VM

• Third exercise: A DSL Compiler for SWTBot• ATL Industrialization• 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


Third Exercise: A DSL Compiler for SWTBotIntent

Provide a simpler syntax for SWTBot (i.e., a Domain-Specific Language or DSL)

Generate Java code from simpler syntax

PrerequisitesSWTBot DSL implementation (metamodel, syntax)SimpleJava metamodel (only what is necessary for

generation of SWTBot code)

RealizationAn ATL transformation from SWTBot to SimpleJava


Third Exercise: A DSL Compiler for SWTBot


ATL Industrialization process

PME

Labo

Users

idea

experimentation

validation

industrialization

partnership commercialization


Roadmap• Roadmap overview:

IndustrializationEMF-VM improvementsStabilizationInternationalizationImprove Eclipse integration

New featuresPackagingIncremental 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


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?

atl tutorial - eclipsecon 2009

Technology

atl description atl

atl atl versions

model transformation

atl m2m

atl wikihttp

atl history

simpler atl transformation

model refactoring architecture