DSL Design. Model Transformations. Model Transformations. Language g Implementation Strategies

(1)

Generic Language Technology 2IS15

g

gy

Model Transformations

Marcel van Amstel

Language Implementation Strategies

g

p

g

• Stand-alone

• Embedding

• Translation

/ Software Engineering and Technology 9-1-2012 PAGE 2

Model Transformations

A model transformation is a

mapping from

a

set of

source models to

a set of

target models

defined as a set of transformation rules.

Model Transformations

• Semi-Thue systems

y

(2)

• Model transformation

/ Faculteit Wiskunde en Informatica 9-1-2012 PAGE 6

Model Transformations

Implementation approaches

p

pp

• Direct model manipulation

• Intermediate representation

• Model transformation language

Model transformations

• Model transformation formalisms

• ATL • Xtend • ASF+SDF • Stratego/XT • Xtext • Xpand • QVT Relations • VIATRA • Tefkat • ETL (Epsilon) • QVT Operations • QVT Core ( p ) • GrGen • …

(3)

• ATL characteristics:

ATL characteristics:

• Hybrid language (declarative and imperative constructs)

• Transformation is a set of transformation rules and helpers

• OCL for source model navigation

• Limited escape mechanism to use Java

• In-place transformation simulated using refining mode

• Documentation: www eclipse org/m2m/atl/doc/ • Documentation: www.eclipse.org/m2m/atl/doc/

• The Atlas Transformation Language (ATL) is a hybrid language (a mix of declarative and imperative constructions) designed to express model transformations

• A model transformation in ATL is expressed as a set of transformation rules

• Hybrid style of programming:

• Declarative transformation based on simple mappings • Imperative for complex mappings

• OCL is used to expression constraints on rules

• Guards (constraints) on the entry point for a rule( ) y p • Documentation:http://www.eclipse.org/gmt/atl/doc

Model transformations

• An ATL transformation program is composed of

g

rules that define how

• source model elements are matched and navigated

• to create and initialize the elements of the target models

• The ATL programs for model to model

transformation are called modules

Model transformations

• An example of an ATL specification

• The goal is to present a use case of a model to model transformation written in ATL

• This use case is named: “Books to Publications”

• Initially we have a text describing a list of books

t a y

e a e a te t desc b g a st o boo s

• We want to transform this into another text

describing a list of publications

(4)

• ATL: Book2Publication example

MMM

MM

MMt

MM

conformsTo _conformsTo conformsTo

MMa MMb conformsTo conformsTo conformsTo Ma M_t Mb Transformation

• ATL: Book2Publication example

Ecore

MM

ATL

MM

conformsTo _conformsTo conformsTo

MMBook MMPublication conformsTo conformsTo conformsTo Book Book2Publication Publication Transformation

Model transformations

• Meta-model of Book:

E

l

f B

k

• Example of Book:

Model transformations

• Meta-model of Publication:

(5)

• First we create an ATL

project

• Getting started

S l t i E li • Select in Eclipse − File/New/ATL Project

• Select then the Finish

b tt button

• First we have to create/

obtain meta-models

N

t

ATL fil

• Next we create an ATL file

• Getting started

• Select in EclipseSelect in Eclipse

− File/New/ATL File

• Select then the Next button

Model transformations

• Next we have to set the

Input/Output parameters

of ATL transformation:

• Select then theSelect then the FinishFinish

button

• This will generate

automatically the header

section

Model transformations

• A detailed description of the transformation can be

found at:

http://wiki.eclipse.org/ATL/Tutorials_-Create a simple ATL transformation _Create_a_simple_ATL_transformation

(6)

• ATL transformation code

• A header section that defines some attributes that are relative to the transformation module

• An optional import section that enables to import some existing ATL libraries

• A set of helpers that can be viewed as an ATL equivalent to Java methods

equivalent to Java methods

• A set of rules that defines the way target models are t d f

generated from source ones

• Header:

• The header section names the transformation module and names the variables corresponding to the source and target models ("IN" and "OUT") together with their meta-models (“Book" and “Publication") acting as types.

module Book2Publication; module Book2Publication;

create OUT : Publication from IN : Book;

Model transformations

• Libraries:

• The optional import section enables to declare which ATL libraries have to be imported

• The declaration of an ATL library is achieved as follows:

uses extensionless library file name; uses extensionless_library_file_name;

• For example:

uses strings;

Model transformations

• ATL helpers

• ATL helpers can be viewed as the ATL equivalent to Java methods

• They make it possible to define factorized ATL code that canThey make it possible to define factorized ATL code that can be called from different points of an ATL transformation

(7)

• An ATL helper is defined by the following elements:

y

g

• a name

• a context type

− The context type defines the context in which this attribute is

− The context type defines the context in which this attribute is defined

− Optional

• a return value type

• a return value type.

− Note that, in ATL, each helper must have a return value • an OCL expression that represents the code of the ATL

helper; helper;

• an optional set of parameters, in which a parameter is identified by a couple (parameter name, parameter type).

• Helper functions:

• A helper is an auxiliary function that computes a

result needed in a rule

helper context Book!Book def : getAuthors() : String = self.chapters->

collect(e | e.author)-> S t() >

asSet()->

iterate(authorName, acc : String = '' | acc +

if acc = ''

if acc

then authorName

else ' and ' + authorName

endif);

Model transformations

Select the chapters Get the authors of _{each chapter} Filter duplicates

helper context Book!Book def : getAuthors() : String = each chapter

self.chapters->

collect(e | e.author)-> asSet()->

iterate(authorName; acc : String = '' | iterate(authorName; acc : String = | acc + if acc = ''

then authorName

else ' and ' + authorName

endif);

Build a list

Model transformations

• To iterate over a collection

source -> iterate(elem, var : Type = init_exp | body )

• var

is an accumulator which gets an initial value

• elem

is an iterator which iterates on each element of

the collection

• For each iteration

body

is

• evaluated and then

(8)

• Helper

• To get the total of pages

helper context Book!Book def : getNbPages() : Integer = self.chapters->

collect(f|f.nbPages)->

iterate(pages, acc : Integer = 0 | acc + pages);

• Alternative

helper context Book!Book def : getNbPagesEasy() : Integer = self.chapters ->

collect(f | f.nbPages) -> sum();

• It is possible to consider a helper that returns the

maximum of two integer values:

• the contextual integer and an additional integer value which is passed as parameter:

is passed as parameter:

helper context Integer def : max(x : Integer) : Integer = ...;

Model transformations

• ATL Rules

• There exist three different kinds of rules that correspond to the two different programming modes

− matched rules (declarative programming),matched rules (declarative programming),

− lazy rules,

− called rules (imperative programming).

Model transformations

• ATL matched rule mechanism provides a mean to

specify the way target model elements must be

generated from source model elements.

• A matched rule enables to specify:

1. which source model element must be matched,

2. the number and the type of the generated target model yp g g elements, and

3. the way these target model elements must be initialized from the matched source elements initialized from the matched source elements

(9)

• Each matched rule is identified by its name (rule_name).

• A matched rule name must be unique within an ATL transformation.

• An ATL matched rule is composed of

• two mandatory sections

− from and to parts.

• two optional sections:two optional sections:

− using and do parts.

• The different variables that may be declared in the scope of a rule (the source and target pattern elements and the local rule (the source and target pattern elements and the local variables) must have a unique name.

• Matched rules

rule rule_name{

from in: MM1!MetaClass(<matching condition>) using{<variable definitions>}

to out1: MM2!MetaClass1( <bindings1> ), out2: MM2!MetaClass2( <bindings2> <bindings2> ) do{<imperative block>} } M t h ll d l l t f t

• Matches on all model elements of type MM1!MetaClass, similar to ASF’s traversal functions

Model transformations

• Rules

rule Book2Publication { from b : Book!Book ( b getNbPages() > 2 ) b : Book!Book ( b.getNbPages() > 2 ) to out : Publication!Publication ( title <- b title title <- b.title, authors <- b.getAuthors(), nbPages <- b.getNbPages() ) } }

Model transformations

• Assigning attributes in ATL rules:

Meta model identification Meta model element identification In/out pattern Attribute assignment rule example1{

from in: MM1!MetaClassA

to out: MM2!MetaClassB(

attr <- in.attr )

(10)

• Source pattern

• The from section corresponds to the rule source pattern.

• This pattern (a single source pattern element) contains

− the source variable declaration (in var) of the type of the sourcethe source variable declaration (in_var) of the type of the source model elements that will be matched by the rule (in_type).

− It may contain, between brackets, an optional boolean expression (condition)

• The following code illustrates the syntax of the from section:

from p : MMPerson!Person o p : e so ! e so (

p.name = 'Smith' )

)

Assignment statement enables

− to assign target model element features

target <- exp;

Model transformations

If statement enables

− to define alternative treatments

if(condition) then { statement1 } else { statement2 } else { statement2 } endif C diti i OCL i

− Condition is an OCL expression

Model transformations

• ATL imperative code

• For statement enables to define iterative imperative

computations:

for(iterator in collection) for(iterator in collection) { statements }

(11)

• The initialization of the attributes of a generated

g

target model element by assigning references:

Model target element generated by current rule

• Model target element generated by current rule

• Default target model element generated by another ruleg g y

• Non-default target model element generated by another rule

rule

• The first case (assigning a model element produced

(

g

by the same rule) is the simplest one:

• the considered reference can be initialized with the name of the other target pattern element

the other target pattern element

• consider the following example in which the rule Case1 has two target pattern model elements (o_1 and o_2), with o_1 having a reference to a Class2 model element defined having a reference to a Class2 model element defined (linkToClass2):

rule Case1 {

from i : MM_A!ClassA _

to o_1 : MM_B!Class1 ( linkToClass2 <- o_2 ), o_2 : MM_B!Class2 ( ... )

}

Model transformations

• In the second case (assigning the default target

(

g

element of another rule):

• the considered reference has to be initialized with the source model element which is matched by the remote rule for model element which is matched by the remote rule for generating the target model element to be assigned

Model transformations

• In the following example, the rule Case2_R1 aims to generate a target model element (o 1) that has a reference to a target model element model element (o_1) that has a reference to a target model element that corresponds to the default target pattern (o_1) of the rule

Case2_R2

• Assuming that the source model element matched by Case2_R1 has a reference (linkToClassB) to the relevant MM A!ClassB source model ( ) _

element, this assignment is expressed as follows:

rule Case2_R1 { from i : MM_A!ClassA to o 1 : MM B!Class1 ( _ _ ( linkToClass2 <- i.linkToClassB ) } rule Case2_R2 { from i : MM_A!ClassB to o_1 : MM_B!Class2 ( ... ), ... }

(12)

rule Case2_R1 { from i : MM_A!ClassA to o_1 : MM_B!Class1 ( linkToClass2 <- i.linkToClassB ) } rule Case2_R2 { from i : MM_A!ClassB to o 1 : MM B!Class2 ( ) to o_1 : MM_B!Class2 ( ... ), ... }

• Alternative (also used in the non-default target element)

rule Case2_R1 {

from i : MM A!ClassA from i : MM_A!ClassA to o_1 : MM_B!Class1 (

linkToClass2 <- thisModule.resolveTemp(i.linkToClassB, ‘o_1’) ) } rule Case2_R2 { from i : MM A!ClassB_ to o_1 : MM_B!Class2 ( ... ), ... }

• Example of assignments

p

g

Model transformations

• Lazy rules

y

• Lazy rules are like matched rules, but are only applied when called by another rule

(13)

• Lazy rules

lazy rule rule_name{ from in: MM1!MetaClass using{<variable definitions>} to out1: MM2!MetaClass1( <bindings1> ), out2: MM2!MetaClass2( <bindings2>g ) do{<imperative block>} }

Generates ne target elements for e er call to the r le

• Generates new target elements for every call to the rule

• Invoked from other rules as follows:

thisModule.rule_name(<model element of type MM1!MetaClass>)

Model transformations

• Unique lazy matched rules

unique lazy rule rule_name{ from in: MM1!MetaClass using{<variable definitions>} to out1: MM2!MetaClass1( <bindings1> ), out2: MM2!MetaClass2( <bindings2>g ) do{<imperative block>} }

Al a s ret rns the same target elements for a gi en so rce

• Always returns the same target elements for a given source element, i.e., target elements are generated only once per source element

Model transformations

• Called rules

• The called rules provide ATL developers with convenient imperative programming facilities.

• Called rules can be seen as a particular type of helpers:Called rules can be seen as a particular type of helpers:

− they have to be explicitly called to be executed and they can accept parameters

− called rules can generate target model elements as matched rules g g do

• A called rule has to be called from an imperative code section, either from a matched rule or another called rule

(14)

• Called rules

[entrypoint]? rule rule_name(<parameters>){

using{<variable definitions>} to out1: MM2!MetaClass1( <bindings1> ), out2: MM2!MetaClass2( <bindings2> <bindings2> ) do{<imperative block>} }

• For generating target elements from imperative code

• No from clause

• Example of a called rule

rule NewPerson (na: String, s_na: String) { to p : MMPerson!Person ( name <- na ) do { p.surname <- s_na } } }

Model transformations

• Besides matched rules, ATL defines an additional

kind of rules enabling to explicitly generate target

model elements from imperative code

• Except for the entrypoint called rule this kind of

• Except for the entrypoint called rule, this kind of

rules must be explicitly called from an ATL

imperative block.

Model transformations

• A called rule is identified by its name (rule_name).

• A called rule name must be unique within an ATL transformation • must not collide with a helper name

• a called rule cannot be called "main"

• A called rule can optionally be declared as the transformation

entrypoint/endpoint.yp p

• an ATL transformation can include one entrypoint/endpoint called rule.

• it is implicitly invoked at the beginning/ending of the transformation execution

(15)

• Helper with context

helper context MM!MetaClass def: helper_name(<parameters>): return_type = let <variable definition>

in <expression>; • Invocation:Invocation:

<model element of type MM!MetaClass>.helper_name(<parameters>) • The context should never be of a collection type

• Helper without contextp

helper def: helper_name(<parameters>): return_type = let <variable definition>

in <expression>; • Invocation: • Invocation:

thisModule.helper_name(<parameters>)

• For OCL functions refer to the ATL user guide

• g

• http://wiki.eclipse.org/ATL/User_Guide_-_Overview_of_the_Atlas_Transformation_Language •

http://wiki.eclipse.org/ATL/User_Guide_-_The_ATL_Language

Quality of Model Transformations

MDE is gaining popularity

Academia

Industry

Quality of Model Transformations

Model transformations are software too

Reuse

Maintenance

Design

Methodology

(16)

1. As-is

Reuse

2. With modify

PAGE 61 9-1-2012

/ Faculteit Wiskunde en Informatica

Maintenance

1. Corrective

2. Adaptive

3. Perfective

PAGE 62 9-1-2012

Quality of Model Transformations

Model transformations are software too

Reuse

Maintenance

Design

Methodology

They should not become the next

maintenance nightmare

g

Quality of Model Transformation

• Internal vs. external quality

y

Q

lit

tt ib t

• Quality attributes

•Understandability M difi bilit •Modularity C l t •Modifiability •Reusability •Completeness •Conciseness

(17)

• Quality assessment techniques

y

• Direct quality assessment M t i

− Metrics

• Indirect quality assessmentd ect qua ty assess e t

PAGE 65 9-1-2012

• Debugging of domain-specific models

• Analysis of domain-specific models

• Determining the effect of a source model change

PAGE 66 9-1-2012