Slides for the mdse-book.com chapter 8: model-to-model transformations
Complete set of slides now available:
Chapter 1 - http://www.slideshare.net/mbrambil/modeldriven-software-engineering-in-practice-chapter-1-introduction
Chapter 2 - http://www.slideshare.net/mbrambil/modeldriven-software-engineering-in-practice-chapter-2-mdse-principles
Chapter 3 - http://www.slideshare.net/jcabot/model-driven-software-engineering-in-practice-chapter-3-mdse-use-cases
Chapter 4 - http://www.slideshare.net/jcabot/modeldriven-software-engineering-in-practice-chapter-4
Chapter 5 - https://www.slideshare.net/mbrambil/modeldriven-software-engineering-in-practice-chapter-5-integration-of-modeldriven-in-development-processes
Chapter 6 - http://www.slideshare.net/jcabot/mdse-bookslideschapter6
Chapter 7 - http://www.slideshare.net/mbrambil/model-driven-software-engineering-in-practice-book-chapter-7-developing-your-own-modeling-language
Chapter 8 - http://www.slideshare.net/jcabot/modeldriven-software-engineering-in-practice-chapter-8-modeltomodel-transformations
Chapter 9 - https://www.slideshare.net/mbrambil/model-driven-software-engineering-in-practice-book-chapter-9-model-to-text-transformations-and-code-generation
Chapter 10 - http://www.slideshare.net/jcabot/mdse-bookslideschapter10managingmodels
This book discusses how approaches based on modeling can improve the daily practice of software professionals. This is known as Model-Driven Software Engineering (MDSE) or, simply, Model-Driven Engineering (MDE).
MDSE practices have proved to increase efficiency and effectiveness in software development. MDSE adoption in the software industry is foreseen to grow exponentially in the near future, e.g., due to the convergence of software development and business analysis.
This book is an agile and flexible tool to introduce you to the MDE and MDSE world, thus allowing you to quickly understand its basic principles and techniques and to choose the right set of MDE instruments for your needs so that you can start to benefit from MDE right away.
The first part discusses the foundations of MDSE in terms of basic concepts (i.e., models and transformations), driving principles, application scenarios and current standards, like the wellknown MDA initiative proposed by OMG (Object Management Group) as well as the practices on how to integrate MDE in existing development processes.
The second part deals with the technical aspects of MDSE, spanning from the basics on when and how to build a domain-specific modeling language, to the description of Model-to-Text and Model-to-Model transformations, and the tools that support the management of MDE projects.
The book covers introductory and technical topics, spanning definitions and orientation in the MD* world, metamodeling, domain specific languages, model transformations, reverse engineering, OMG's MDA, UML, OCL, ATL, QVT, MOF, Eclipse, EMF, GMF, TCS, xText.
http://www.mdse-book.com
2. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Content
§ Introduction
§ Out-place Transformations: ATL
§ In-place Transformations: Graph Transformations
§ Mastering Model Transformations
3. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
www.mdse-book.com
INTRODUCTION
4. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Motivation
Transformations are everywhere!
§ Before MDE
§ Program compilation, refactoring, migration, optimization, ...
§ With MDE
§ Transformations are key technologies!
§ Every systematic manipulation of a
model is a model transformation!
§ Dimensions
§ Horizontal vs. vertical
§ Endogenous vs. exogenous
§ Model-to-text vs. text-to-model vs. model-to-model
[Excerpt of MDA Guide
from the OMG]
PIM
PSM
PIM
PSM
MLA MLB
Code Code
PLA PLB
5. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Meta-
Metamodel
Metamodel
Model
M3
M2
M1
Definitions
§ A model-to-model (M2M) transformation is the automatic creation of
target models from source models.
§ 1-to-1 transformations
§ 1-to-N, N-to-1, N-to-M transformations
§ target model* = T(source model*)
Focus of model transformations,
but not limited to M1
(remember: everything is a model!)
Metamodeling Stack
A B C
X Y Z
MT
source model
target model
Example
6. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Architecture
Model-to-Model Transformation Pattern
MOF
MMa MMb
Ma Mba2b.mt
MMTLsource metamodel
source model target model
target metamodel
conformsTo
Execution Engine
conformsTo conformsTo
conformsTo
conformsTo
conformsTo
7. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Two Transformation Strategies
Out-place vs. in-place transformations
Transformation
Specification
ModelA
MetamodelA
ModelB
MetamodelB
Transformation
Specification
ModelA
MetamodelA
Legend:
Transformation
Execution
Dependency
«conformsTo» «conformsTo» «conformsTo»
Out-place Transformations build
a new model from scratch
In-place Transformations change
some parts in the model
8. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Two Transformation Strategies
Out-place vs. in-place transformations
For each green element,
create a blue element.
For each green element,
create a blue element.
Delete all elemens except
blue ones.
Out-place Transformation In-place Transformation
Example #1
9. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Two Transformation Strategies
Out-place vs. in-place transformations
Out-place Transformation In-place Transformation
Example #2
For each green element,
create a blue element.
For each green element,
create a green element.
For each red element,
create a red element.
For each green element,
create a blue element.
10. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Architecture
Illustrative Example
G 2 P
Rule
R 2 B
Rule
Ma Mb
MMa
Green
Class
Red
Class
MMb
Blue
Class
Pink
Class
Meta-metamodel
Class
Class
ATL
Rule
Class
MMa2MMb.atl
conformsTo
conformsTo
conformsTo
conformsTo
conformsTo
conformsTo
conformsTo
execution
Out-place Transformations
11. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Architecture
Concrete Example
Java M
conformsTo
A 2 V
Rule
C 2 C
Rule
UML2Java.atl
execution
UML M
conformsTo
c1:Class
a1:Attribute
Trace Model
c1 -> c01 : C2C
a1 -> v01 : A2V
MMa
Class
Attribute
* attributes
Java MM
Class
Variable
* variables
v01:Variable
c01:Class
UML MM
Out-place Transformations
12. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Architecture
Illustrative Example
R 2 G
Rule
Ma
MMa
Green
Class
Red
Class
Meta-metamodel
Class
Class
GT
Rule
Class
MMa.gt
conformsTo
conformsTo
conformsTo
conformsTo
In-place Transformations
Ma’ Ma’’
conformsTo
MMa
13. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Architecture
Concrete Example
Pub2Pri
Rule
Pub2PriRef.gt
UML M
conformsTo
c1:Class
a1:Attribute
Trace Model
a1 -> Pub2Pri
MMa Class
Attribute
*
attributes
UML
MM
In-place Transformations
visibility
visibility = public
UML M’
c1:Class
a1:Attribute
visibility = private
14. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
www.mdse-book.com
OUT-PLACE
TRANSFORMATIONS:
ATLAS TRANSFORMATION LANGUAGE
15. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
ATL overview
§ Source models and target models are distinct
§ Source models are read-only
§ Target models are write-only
§ The language is a declarative-imperative hybrid
§ Declarative part
§ Matched rules with automatic traceability support
§ Side-effect free query language: OCL
§ Imperative part
§ Called/Lazy rules
§ Action blocks
§ Global variables via Helpers
§ Recommended programming style: declarative
16. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
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 optional action block (i.e., a sequence of imperative statements)
§ An imperative rule is basically a procedure
§ It is called by its name
§ It may take arguments
§ It contains
§ A declarative target pattern
§ An optional action block
17. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
ATL overview (continued)
§ Applying a rule means
1. Creating the specified target elements
2. Initializing the properties of the newly created elements
§ There are two types of rules concerning their application
§ Matched rules are applied once for each match by the execution
engine
§ A given set of elements may only be matched by one matched rule
§ Called/Lazy rules are applied as many times as they are called from
other rules
18. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Matched rules: Overview
§ A Matched rule is composed of
§ A source pattern
§ A target pattern
§ An optional action block
Matched Rule
Source Pattern Target Pattern
Source Model Target Model
queries generates
accesses
1 1
Action Block
0..1
accesses
accesses
19. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
rule Rule1{
from
v1 : SourceMM!Type1(cond1)
to
v2 : TargetMM!Type1 (
prop <- v1.prop
)
}
Matched rules: source pattern
§ The source pattern is composed of
§ A set of labeled source pattern elements
§ A source pattern element refers to a type contained in the source metamodels
§ A guard (Boolean OCL expression) used to filter matches
§ A match corresponds to a set of elements coming from the source
models that
§ Fulfill the types specified by the source pattern elements
§ Satisfy the guard
20. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Matched rules: target pattern
§ The target pattern is composed of
§ A set of labeled target pattern elements
§ Each target pattern element
§ refers to a type in the target metamodels
§ contains a set of bindings
§ A binding initializes a property of a target element using an OCL expression
§ For each match, the target pattern is applied
§ Elements are created in the target models
§ Target elements are initialized by executing the bindings
rule Rule1{
from
v1 : SourceMM!Type1(cond1)
to
v2 : TargetMM!Type1 (
prop <- v1.prop
)
}
21. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Example #1 – Publication 2 Book
Journal
name: String
Book
name: String
id: Integer
Source Metamodel Target Metamodel
j2:Journal
name = ACM Comp. Sur.
j3:Journal
name = IEEE Software.
j1:Journal
name = IEEE Computer
b2:Book
name = ACM Comp. Sur.
id = 2
b3:Book
name = IEEE Software.
id = 3
b1:Book
name = IEEE Computer
id = 1
Journal
Collection
Book
Collection
jc1:Journal
Collection
bc1:Book
Collection
Concepts
1) Matched Rule
2) Helper
Source Model Target Model
journals books
1..* 1..*
22. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Example #1
Configuration of Source/Target Metamodels
§ Header
module Publication2Book;
create OUT : Book from IN : Publication;
§ For code completion
§ --@path MM_name =Path_to_metamodel_definition
§ Activate code completion: CTRL + space
23. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Example #1
Matched Rules
§ Example Publication 2 Book
module Publication2Book;
create OUT : Book from IN : Publication;
rule Collection2Collection {
from
jc : Publication!JournalCollection
to
bc : Book!BookCollection(
books <- jc.journals
)
}
rule Journal2Book {
from
j : Publication!Journal
to
b : Book!Book (
name <- j.name
)
}
Source Pattern
Target Pattern
Matched Rule
Header
Binding
24. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Example #1
Helpers 1/2
§ Syntax
helper context Type def : Name(Par1 : Type, …) : Type = EXP;
§ Global Variable
helper def: id : Integer = 0;
§ Global Operation
helper context Integer def : inc() : Integer = self + 1;
§ Calling a Helper
§ thisModule.HelperName(…) – for global variables/operations without context
§ value.HelperName(…) – for global variables/operations with context
25. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Example #1
Helpers 2/2
§ Example Publication 2 Book
module Publication2Book;
create OUT : Book from IN : Publication;
helper def : id : Integer = 0;
helper context Integer def : inc() : Integer = self + 1;
rule Journal2Book {
from
j : Publication!Journal
to
b : Book!Book (
name <- j.name
)
do {
thisModule.id <- thisModule.id.inc();
b.id <- thisModule.id;
}
}
Action
Block
Global Variable
Global Operation
Module Instance for accessing global variables
Global Operation call
26. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Example #2 – Person 2 Customer
Person
name: String
age : Integer
gender : {male,
female}
Customer
name: String
gender: {male,
female}PSystem
CSystem
*
*
c2:Customer
name = javi
c1:Customer
name = hugo
p2:Person
name = javi
age= 45
gender = female
p3:Person
name = bill
age = 12
gender = male
p1:Person
name = hugo
age = 21
gender = male
s1:PSystem
s1:CSystem
Constraint: Customer must be
older than 18 years
Concepts:
1) Guards
2) Trace Model
3) Called/Lazy Rule Source Metamodel Target Metamodel
Source Model Target Model
27. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Example #2
Describing more complex correspondences and bindings
§ Declarative Statements
§ If/Else, OCL Operations, Global Operations, …
§ Application: Guard Condition and Feature Binding
§ Example: IF/ELSE
if condition then
exp1
else
exp2
endif
28. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Example #2
Guards Conditions in Source Patterns
§ Example Person2Customer
rule Person2Customer {
from
p : Person!Person (p.age > 18)
to
c : Customer!Customer (
name <- p.name
)
}
rule PSystem2CSystem {
from
ps : Person!PSystem
to
cs : Customer!CSystem (
customer <- ps.person -> select(p | p.age > 18)
)
}
Guard Condition
Compute Subset for
Feature Binding
29. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Example #2
Implicit Trace Model – Phase 1: Module Initialization Phase
rule PSystem2CSystem {
from
ps : Person!PSystem
to
cs : Customer!CSystem (
customer <- ps.person
)
}
rule Person2Customer {
from
p : Person!Person(p.age > 18)
to
c : Customer!Customer (
name <- p.name
)
}
p1:Person
name = hugo
age = 21
p3:Person
name = bill
age = 12
s1:PSystem
:TransientLinkSet
Trace Model is a set (cf. TransientLinkSet) of links
(cf. TransientLink) that relate source elements with
their corresponding target elements
30. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Example #2
Implicit Trace Model – Phase 2: Matching Phase
rule PSystem2CSystem {
from
ps : Person!PSystem
to
cs : Customer!CSystem (
customer <- ps.person
)
}
rule Person2Customer {
from
p : Person!Person(p.age > 18)
to
c : Customer!Customer (
name <- p.name
)
}
p1:Person
name = hugo
age = 21
p3:Person
name = bill
age = 12
s1:PSystem
:TransientLinkSet
31. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Example #2
Implicit Trace Model – Phase 2: Matching Phase
rule PSystem2CSystem {
from
ps : Person!PSystem
to
cs : Customer!CSystem (
customer <- ps.person
)
}
rule Person2Customer {
from
p : Person!Person(p.age > 18)
to
c : Customer!Customer (
name <- p.name
)
}
p1:Person
name = hugo
age = 21
p3:Person
name = bill
age = 12
s1:PSystem
TL1:TransientLink
:TransientLinkSet
rule = PSystem2CSystem
ps
32. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Example #2
Implicit Trace Model – Phase 2: Matching Phase
rule PSystem2CSystem {
from
ps : Person!PSystem
to
cs : Customer!CSystem (
customer <- ps.person
)
}
rule Person2Customer {
from
p : Person!Person(p.age > 18)
to
c : Customer!Customer (
name <- p.name
)
}
p1:Person
name = hugo
age = 21
p3:Person
name = bill
age = 12
s1:PSystem
TL1:TransientLink
:TransientLinkSet
rule = PSystem2CSystem
ps
s1:CSystem
cs
33. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Example #2
Implicit Trace Model – Phase 2: Matching Phase
rule PSystem2CSystem {
from
ps : Person!PSystem
to
cs : Customer!CSystem (
customer <- ps.person
)
}
rule Person2Customer {
from
p : Person!Person(p.age > 18)
to
c : Customer!Customer (
name <- p.name
)
}
p1:Person
name = hugo
age = 21
p3:Person
name = bill
age = 12
s1:PSystem
TL1:TransientLink
:TransientLinkSet
rule = PSystem2CSystem
ps
s1:CSystem
cs
34. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Example #2
Implicit Trace Model – Phase 2: Matching Phase
rule PSystem2CSystem {
from
ps : Person!PSystem
to
cs : Customer!CSystem (
customer <- ps.person
)
}
rule Person2Customer {
from
p : Person!Person(p.age > 18)
to
c : Customer!Customer (
name <- p.name
)
}
p1:Person
name = hugo
age = 21
p3:Person
name = bill
age = 12
s1:PSystem
TL1:TransientLink
:TransientLinkSet
rule = PSystem2CSystem
ps
s1:CSystem
cs
TL2:TransientLink
rule = Person2Customer
p
35. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Example #2
Implicit Trace Model – Phase 2: Matching Phase
rule PSystem2CSystem {
from
ps : Person!PSystem
to
cs : Customer!CSystem (
customer <- ps.person
)
}
rule Person2Customer {
from
p : Person!Person(p.age > 18)
to
c : Customer!Customer (
name <- p.name
)
}
p1:Person
name = hugo
age = 21
p3:Person
name = bill
age = 12
s1:PSystem
TL1:TransientLink
:TransientLinkSet
rule = PSystem2CSystem
ps
s1:CSystem
cs
TL2:TransientLink
rule = Person2Customer
p
c1:Customer
c
36. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Example #2
Implicit Trace Model – Phase 2: Matching Phase
rule PSystem2CSystem {
from
ps : Person!PSystem
to
cs : Customer!CSystem (
customer <- ps.person
)
}
rule Person2Customer {
from
p : Person!Person(p.age > 18)
to
c : Customer!Customer (
name <- p.name
)
}
p1:Person
name = hugo
age = 21
p3:Person
name = bill
age = 12
s1:PSystem
TL1:TransientLink
:TransientLinkSet
rule = PSystem2CSystem
ps
s1:CSystem
cs
TL2:TransientLink
rule = Person2Customer
c1:Customer
p
c
37. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Example #2
Implicit Trace Model – Phase 3: Target Initialization Phase
rule PSystem2CSystem {
from
ps : Person!PSystem
to
cs : Customer!CSystem (
customer <- ps.person
)
}
rule Person2Customer {
from
p : Person!Person(p.age > 18)
to
c : Customer!Customer (
name <- p.name
)
}
p1:Person
name = hugo
age = 21
p3:Person
name = bill
age = 12
s1:PSystem
TL1:TransientLink
:TransientLinkSet
rule = PSystem2CSystem
ps
s1:CSystem
cs
TL2:TransientLink
rule = Person2Customer
c1:Customer
p
c
38. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Example #2
Implicit Trace Model – Phase 3: Target Initialization Phase
rule PSystem2CSystem {
from
ps : Person!PSystem
to
cs : Customer!CSystem (
customer <- ps.person
)
}
rule Person2Customer {
from
p : Person!Person(p.age > 18)
to
c : Customer!Customer (
name <- p.name
)
}
p1:Person
name = hugo
age = 21
p3:Person
name = bill
age = 12
s1:PSystem
TL1:TransientLink
:TransientLinkSet
rule = PSystem2CSystem
ps
s1:CSystem
cs
TL2:TransientLink
rule = Person2Customer
c1:Customer
p
c
39. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Example #2
Implicit Trace Model – Phase 3: Target Initialization Phase
rule PSystem2CSystem {
from
ps : Person!PSystem
to
cs : Customer!CSystem (
customer <- ps.person
)
}
rule Person2Customer {
from
p : Person!Person(p.age > 18)
to
c : Customer!Customer (
name <- p.name
)
}
p1:Person
name = hugo
age = 21
p3:Person
name = bill
age = 12
s1:PSystem
TL1:TransientLink
:TransientLinkSet
rule = PSystem2CSystem
ps
s1:CSystem
cs
TL2:TransientLink
rule = Person2Customer
c1:Customer
name = hugo
p
c
40. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Example #2
Implicit Trace Model – Phase 3: Target Initialization Phase
rule PSystem2CSystem {
from
ps : Person!PSystem
to
cs : Customer!CSystem (
customer <- ps.person
)
}
rule Person2Customer {
from
p : Person!Person(p.age > 18)
to
c : Customer!Customer (
name <- p.name
)
}
p1:Person
name = hugo
age = 21
p3:Person
name = bill
age = 12
s1:PSystem
TL1:TransientLink
:TransientLinkSet
rule = PSystem2CSystem
ps
s1:CSystem
cs
TL2:TransientLink
rule = Person2Customer
c1:Customer
name = hugo
p
c
41. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Example #2
Implicit Trace Model – Phase 3: Target Initialization Phase
rule PSystem2CSystem {
from
ps : Person!PSystem
to
cs : Customer!CSystem (
customer <- ps.person
)
}
rule Person2Customer {
from
p : Person!Person(p.age > 18)
to
c : Customer!Customer (
name <- p.name
)
}
p1:Person
name = hugo
age = 21
p3:Person
name = bill
age = 12
s1:PSystem
TL1:TransientLink
:TransientLinkSet
rule = PSystem2CSystem
ps
s1:CSystem
cs
TL2:TransientLink
rule = Person2Customer
c1:Customer
name = hugo
p
c
42. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Transformation Execution Phases
1. Module Initialization Phase
§ Module variables (attribute helpers) and trace model are initialized
§ If an entry point called rule is defined, it is executed in this step
2. Matching Phase
§ Using the source patterns (from) of matched rules, elements are selected in
the source model (each match has to be unique)
§ Via the target patterns (to) corresponding elements are created in the target
model (for each match there are as much target elements created as target
patterns are used)
§ Traceability information is stored
3. Target Initialization Phase
§ The elements in the target model are initialized based on the bindings (<-)
§ The resolveTemp function is evaluated, based on the traceability information
§ Imperative code (do) is executed, including possible calls to called rules
43. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Example #2
Alternative Solution with Called Rule and Action Block (1/3)
Imperative Statements in Action Blocks (do)
IF/[ELSE]
if( aPerson.gender = #male )
thisModule.men->including(aPerson);
else
thisModule.women->including(aPerson);
FOR
for( p in Person!Person.allInstances() ) {
if(p.gender = #male)
thisModule.men->including(p);
else
thisModule.women->including(p);
}
44. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Example #2
Alternative Solution with Called Rule and Action Block (2/3)
rule PSystem2CSystem {
from
ps : Person!PSystem
to
cs : Customer!CSystem ()
do{
for( p in Person!Person.allInstances() ) {
if(p.age > 18)
cs.customer <- thisModule.NewCustomer(p.name,
p.gender);
}
}
}
Matched Rule
Called Rule Call
Action Block
Explicit Query on
Source Model
Binding
45. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Example #2
Alternative Solution with Called Rule and Action Block (3/3)
rule NewCustomer (name: String, gender: Person::Gender){
to
c : Customer!Customer (
c.name <- name
)
do {
c.gender <- gender;
c;
}
}
Target Pattern
Action Block
Called Rule
Result of Called Rules is the last statement
executed in the Action Block
46. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Example #2
Alternative Solution with Lazy Rule and Action Block (1/2)
rule PSystem2CSystem {
from
ps : Person!PSystem
to
cs : Customer!CSystem (
)
do{
for( p in Person!Person.allInstances() ) {
if(p.age > 18)
cs.customer <- thisModule.NewCustomer(p);
}
}
}
Matched Rule
Lazy Rule Call
Action Block
Explicit Query on
Source Model
Binding
47. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Example #2
Alternative Solution with Lazy Rule and Action Block (2/2)
lazy rule NewCustomer{
from
p : Person!Person
to
c : Customer!Customer (
name <- p.name,
gender <- p.gender
)
}
Lazy Rule
Source Pattern
Target Pattern
Result of Lazy Rules is the first specified
target pattern element
48. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Example #3
Resolve Temp – Explicitly Querying Trace Models (1/4)
Element
name: String
Set
Element
name: String
Container
1
id : Int
info : String
rule Set2Container {
from
b : source!Set
to
d : target!Description(
text <- b.info
),
c : target!Container(
id <- b.id,
description <- d
)
}
id: Int
Description
text: String
1
1
rule Element2Element{
from
eS : source!Element
to
eT : target!Element (
name <- eS.name,
container <- thisModule.resolveTemp(
eS.set, ‘c’)
)
}
Source Metamodel Target Metamodel
Transformation
49. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Example #3
Resolve Temp – Explicitly Querying Trace Models (2/4)
e1:Element
name = Element1
b1:Set
TL1:TransientLink
:TransientLinkSet
rule = Set2Container
b
d1:Description
d
TL2:TransientLink
rule = Element2Element
eS
eT
c1:Container
rule Set2Container {
from
b : source!Set
to
d : target!Description(
text <- b.info
)
c : target!Container(
id <- b.id,
description <- d
)
}
rule Element2Element{
from
eS : source!Element
to
eT : target!Element (
name <- eS.name,
container <-thisModule.resolveTemp(
eS.set, ‘c’)
)
}
id = 1
info = „In …“
text = „In …“
id = 1
e1:Element
name = Element1
c
50. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Example #3
Resolve Temp – Explicitly Querying Trace Models (3/4)
e1:Element
name = Element1
b1:Set
TL1:TransientLink
:TransientLinkSet
rule = Set2Container
d1:Description
TL2:TransientLink
rule = Element2Element
c1:Container
id = 1
info = „In …“
text = „In …“
id = 1
e1:Element
name = Element1
rule Set2Container {
from
b : source!Set
to
d : target!Description(
text <- b.info
)
c : target!Container(
id <- b.id,
description <- d
)
}
rule Element2Element{
from
eS : source!Element
to
eT : target!Element (
name <- eS.name,
container <-thisModule.resolveTemp(
eS.set, ‘c’)
)
}
b
d
eS
eTc
51. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Example #3
Resolve Temp – Explicitly Querying Trace Models (4/4)
e1:Element
name = Element1
b1:Set
TL1:TransientLink
:TransientLinkSet
rule = Set2Container
d1:Description
TL2:TransientLink
rule = Element2Element
c1:Container
id = 1
info = „In …“
text = „In …“
id = 1
e1:Element
name = Element1
rule Set2Container {
from
b : source!Set
to
d : target!Description(
text <- b.info
)
c : target!Container(
id <- b.id,
description <- d
)
}
rule Element2Element{
from
eS : source!Element
to
eT : target!Element (
name <- eS.name,
container <-thisModule.resolveTemp(
eS.set, ‘c’)
)
}
b
d
eS
eTc
52. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
ATL Data Types
OCL Operations for each Type
53. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Rule inheritance
§ Rule inheritance allows for reusing transformation rules
§ A child rule may match a subset of what its parent rule matches
§ All the bindings and filters of the parent still make sense for the child
§ A child rule may specialize target elements of its parent rule
§ Initialization of existing elements may be specialized
§ A child rule may extend target elements of its parent rule
§ New elements may be created
§ A parent rule may be declared as abstract
§ Then the rule is not executed, but only reused by its children
§ Syntax
abstract rule R1 {
...
}
rule R2 extends R1 {
...
}
54. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Rule inheritance
Example #1
Person
name: String
Entity
name: String
Customer
id: String
Client
id: String
abstract rule Person2Entity {
from
p : source!Person
to
e : target!Entity(
name <- p.name
)
}
rule Customer2Client extends Person2Entity{
from
p : source!Customer
to
e : target!Client (
id <- p.id
)
}
Source MM Target MM
55. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Rule inheritance
Example #2
Person
name: String
Entity
name: String
Customer
id: String
Client
id: String
rule Person2Entity {
from
p : source!Person
to
e : target!Entity(
name <- p.name
)
}
rule Customer2Client extends Person2Entity{
from
p : source!Customer
to
e : target!Client (
id <- p.id
)
}
Source MM Target MM
56. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Debugging Hints
§ Quick and Dirty: Make use of .debug()
§ Proceed in tiny increments
§ Immediately test changes
§ Read Exception Trace
§ Look top-down the stack trace for „ERROR“ to find meaningful
message:
§ Check line number:
§ do-blocks can be used for temporary debug output
Line number
57. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
ATL in Use
§ ATL tools and documentation are available at http://
www.eclipse.org/atl
§ Execution engine
§ Virtual machine
§ ATL to byte code compiler
§ Integrated Development Environment (IDE) for
§ Editor with syntax highlighting and outline
§ Execution support with launch configurations
§ Source-level debugger
§ Documentation
§ Starter’s guide
§ User manual
§ User guide
§ Basic examples
58. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Summary
§ ATL is specialized in out-place model transformations
§ Simple problems are generally solved easily
§ ATL supports advanced features
§ Complex OCL navigation, called rules, refining mode, rule inheritance, etc
§ Many complex problems can be handled declaratively
§ ATL has declarative and imperative features
§ Any out-place transformation problem can be handled
§ Further information
§ Documentation:
http://wiki.eclipse.org/ATL/User_Guide_-_The_ATL_Language
§ Examples: http://www.eclipse.org/m2m/atl/basicExamples_Patterns
59. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Alternatives to ATL
§ QVT: Query-View-Transformation standard of the OMG
§ Declarative QVT Relational language
§ Imperative QVT Operational language
§ Low-level QVT Core language (VM level)
§ TGG: Triple Graph Grammars
§ Correspondence graphs between metamodels
§ Transform models in both directions, integrate and synchronize models
§ JTL: Janus Transformation Language
§ Strong focus on model synchronization by change propagating
§ ETL: Epsilon Transformation Language
§ Designated language in the Epsilon framework for out-place transformations
§ RubyTL: Ruby Transformation Language
§ Extension of the Ruby programming language
§ Core concepts for out-place model transformations (extendable)
§ Many more languages such as VIATRA, Tefkat, Kermeta, or SiTra, …
60. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
www.mdse-book.com
IN-PLACE
TRANSFORMATIONS:
GRAPH TRANSFORMATIONS
61. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Why graph transformations?
§ Models are graphs
§ Class diagram, Petri net, State machine, …
§ Type Graph:
§ Generalization of graph elements
§ Graph transformations
§ Generalization of the graphs’ evolutions
§ Graph transformations are applicable for models!
Type Graph
Graph
Metamodel
Model
represents
represents
conformsTo conformsTo
Graph
Transformations
Model
Transformations
62. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Basics: Directed graph
§ A directed graph G consists of two disjoint sets
§ Vertices V (Vertex)
§ Edges E (Edge)
§ Each edge has a source vertex s and a target vertex t
§ Summarized: G = (V, E, s: E → V, t: E → V)
§ Example graph
§ V = {1, 2, 3}
§ E = {a, b, c}
§ s(a) = 2
§ t(a) = 1
§ s(b) = 3
§ t(b) = 2
§ …
1
2
3
a b
c
63. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
TypeGraph
Typed attributed graph (1/3)
§ To represent models further information is needed
§ Typing: Each vertex and each edge has a type
§ Attribution: Each vertex/edge has an arbitrary number of name/value pairs
§ Notation for directed, typed and attributed graphs
§ Graph is represented as an object diagram
§ Type graph is represented as a class diagram
§ Example
1 : ShippingCompany
name = „LKW Maier“
Graph
1 : Truck
load = 0
2 : Truck
load = 10
1 : Store
name = „CompStore“
containers = 0
ShippingCompany
name : String
Truck
load: Integer
Store
name : String
containers : Integer
*
Container
weight : Integer
0..1
1 : Container
weight = 10
0..1
in
inFrontOf
on
on
inFrontOf
trucks
trucks
trucks
0..1
Example taken from: C. Ermel, M. Rudolf, and G. Taentzer, The AGG approach: Language and environment, Handbook of Graph
Grammars and Computing by Graph Transformation, Application, Languages and Tools, volume 2, World Scientific, 1999.
64. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan Claypool 2012.
Typed attributed graph (2/3)
§ Object diagram
§ Instance of class diagram
§ Basic concepts
§ Object : Instance of class
§ Value: Instance of attribute
§ Link: Instance of reference
1 : Truck
load = 0
1 : Store
name = „CompStore“
inFrontOf
ObjectID : Class name
Attribute name = Value
Reference name
Truck
load: Integer
Store
name : String
…
0..1
inFrontOf
«instanceOf»
«instanceOf»
«instanceOf» «instanceOf»
«instanceOf»
65. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan Claypool 2012.
Typed attributed graph (3/3)
§ Question: How does the type graph look in pure graph shape (object
diagram)?
TypeGraph
ShippingCompany
name : String
Truck
load: Integer
Store
name : String
containers : Integer
*
Container
weight : Integer
0..1
0..
1in
inFrontOf
on
trucks
0..1
66. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan Claypool 2012.
Typed attributed graph (3/3)
§ Question: How does the type graph look in pure graph shape (object
diagram)?
TypeGraph
ShippingCompany
name : String
Truck
load: Integer
Store
name : String
containers : Integer
*
Container
weight : Integer
0..1
0..
1in
inFrontOf
on
trucks
1 : Class
name = „ShippingCompany“
1 : Attribute
name = „name“
type = „String“
1 : Reference
lower = 0
upper = -1
name = „trucks“
2 : Class
name = „Truck“
type
attributes
references
…
0..1
67. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan Claypool 2012.
Until now…
§ …we considered models as static entities
§ A modeler creates a model using an editor – Done!
§ But what is about dynamic model modifications?
§ They are needed for
§ Simulation
§ Execution
§ Animation
§ Transformation
§ Extension
§ Improvement
§ …
§ How can graphs be modified?
§ Imperative: Java Program + Model API
§ Declarative: Graph transformations by means of graph transformation rules
68. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan Claypool 2012.
Example
§ Operation: Loading of Container onto a Truck
§ How can this behaviour be described in a generic way?
1 : ShippingCompany
name = „LKW Maier“
1 : Truck
load = 0
1 : Store
name = „CompStore“
containers = 1
1 : Container
weight = 10
1 : ShippingCompany
name = „LKW Maier“
1 : Truck
load = 10
1 : Store
name = „CompStore“
containers = 0
1 : Container
weight = 10
before after
loading()
inFrontOf
inFrontOf
in
on
trucks
trucks
69. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan Claypool 2012.
Graph transformation rule
§ A graph transformation rule p: L → R is a structure preserving, partial
mapping between two graphs
§ L and R are two directed, typed and attributed graphs themselves
§ Structure preserving, because vertices, edges and values may be preserved
§ Partial, because vertices and edges may be added/deleted
§ Example: Loading of Container onto a Truck
1 : Container
2 : Truck
3 : Store
in
4:inFrontOf
1 : Container
2 : Truck
3 : Store
4:inFrontOf
on
L
R
Pre-condition Post-condition
70. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan Claypool 2012.
Graph transformation rule
§ Structure preserving
§ All vertices and edges which are contained in the set L ∩ R
§ Example
1 : Container
2 : Truck
3 : Store
in
4:inFrontOf
1 : Container
2 : Truck
3 : Store
4:inFrontOf
on
L
R
71. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan Claypool 2012.
Graph transformation rule
§ Adding
§ All vertices and edges which are contained in the set R L
§ Example
1 : Container
2 : Truck
3 : Store
in
4:inFrontOf
1 : Container
2 : Truck
3 : Store
4:inFrontOf
on
L
R
72. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan Claypool 2012.
Graph transformation rule
§ Deleting
§ All vertices and edges which are contained in the set L R
§ Example
1 : Container
2 : Truck
3 : Store
in
4:inFrontOf
1 : Container
2 : Truck
3 : Store
4:inFrontOf
on
L
R
73. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan Claypool 2012.
Graph transformation rule
§ Calculating – Make use of attributes
§ Constants
§ Variables
§ Expressions (OCL Co)
§ Example
1 : Container
weight = x
2 : Truck
load = 0
3 : Store
containers = y
in
4:inFrontOf
1 : Container
weight = x
2 : Truck
load = x
3 : Store
containers = y-1
4:inFrontOf
on
L
R
constraints assignments
74. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan Claypool 2012.
Graph transformation
§ A graph transformation t: G → H is the result of the execution of a
graph transformation rule p: L → R in the context of G
§ t = (p,m) where m: L → G is an injective graph morphism (match)
L
R
G
p
m
H
75. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan Claypool 2012.
Graph transformation
Operational specification
§ Prepare the transformation
§ Select rule p: L - R
§ Select match m: L - G
§ Generate new graph H by
§ Deletion of L R
§ Addition of R L
L
R
G
p
m
H
76. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan Claypool 2012.
Graph transformation example (1/2)
p
m
1 : Container
weight = x
2 : Truck
load = 0
3 : Store
containers = y
in
4:inFrontOf
1 : Container
weight = x
2 : Truck
load = x
3 : Store
containers = y-1
4:inFrontOf
on
L R
1 : ShippingCompany
name = „LKW Maier“
1 : Truck
load = 0
2 : Truck
load = 100
1 : Store
name = „CompStore“
containers = 1
1 : Container
weight = 10
1 : ShippingCompany
name = „LKW Maier“
1 : Truck
load = 10
2 : Truck
load = 100
1 : Store
name = „CompStore“
containers = 0
1 : Container
weight = 10
graphtransformationrulegraphtransformation
G H
77. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan Claypool 2012.
Graph transformation example (2/2)
p
m
a : Container
weight = x
c : Truck
load = 0
b : Store
containers = y
in
4:inFrontOf
a : Container
weight = x
c : Truck
load = x
b : Store
containers = y-1
4:inFrontOf
on
L R
1 : ShippingCompany
name = „LKW Maier“
1 : Truck
load = 0
2 : Truck
load = 100
1 : Store
name = „CompStore“
containers = 1
1 : Container
weight = 10
1 : ShippingCompany
name = „LKW Maier“
1 : Truck
load = 10
2 : Truck
load = 100
1 : Store
name = „CompStore“
containers = 0
1 : Container
weight = 10
graphtransformation
G H
graphtransformationrule
78. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan Claypool 2012.
Graph transformations in ATL
§ Graph transformation
§ ATL (Refining Mode)
rule Loading {
from
a : Container (a.in = b)
b : Store
c : Truck (c.inFrontOf = b AND c.load = 0)
to
_a : Container(weight - a.weight, on - _c)
_b : Store(containers - b.containers - 1)
_c : Truck(load - a.weight, inFrontOf - _b)
}
a : Container
weight = x
c : Truck
load = 0
b : Store
containers = y
in
4:inFrontOf
a : Container
weight = x
c : Truck
load = x
b : Store
containers = y-1
4:inFrontOf
on
L R
79. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan Claypool 2012.
Negative Application Condition (NAC)
§ Left side of a rule specifies what must be existing to execute the
rule
§ Application Condition
§ Often needed to describe what must not be existing
§ Negative Application Condition (NAC)
§ NAC is a graph which describes a forbidden sub graph structure
§ Absence of specific vertices and edges must be granted
§ Graph transformation rule is executed when NAC is not fulfilled
80. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan Claypool 2012.
Negative Application Condition (NAC)
§ Example: A truck should only be loaded if there is no container on the truck
1 : Container
weight = x
2 : Truck
load = 0
3 : Store
containers = y
in
4:inFrontOf
1 : Container
weight = x
2 : Truck
load = x
3 : Store
containers = y-1
4:inFrontOf
on
L
R
: Container
2 : Truck
on
NAC
Advanced Pre-condition Post-condition
81. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan Claypool 2012.
Negative Application Condition (NAC)
§ Multiple NACs for one rule possible
§ But: LHS and RHS must only be specified once
82. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan Claypool 2012.
Multi-Object
§ The number of matching objects is not always known in advance
§ Maximal set of objects which fulfill a certain condition
§ Selection of all objects x from a set y which fulfill condition z
§ In OCL: y - select(x | z(x))
§ Notation: Multi-Object from UML 1.4
§ A multi-object symbol maps to a collection of instances in which each instance
conforms to a given type and conditions
§ Example: select(x | x.oclIsTypeOf(Type))
id : Type
83. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan Claypool 2012.
Execution order of graph transformation rules
§ A graph transformation system consists of a set of different graph
transformation rules
§ In which order are they being executed?
§ Multiple procedures
§ nondeterministic
§ deterministic
§ Priorities
§ Programs (aka „programmable graph transformations“)
§ Example – Specialized UML activity diagrams
§ [failure]
§ [success]
85. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan Claypool 2012.
Summary
§ Model transformations are graph transformations
§ Type Graph = Metamodel
§ Graph = Model
§ Programmable graph transformations allow for the development
of complex graph evolution scenarios
§ Exogenous, out-place transformations can also be specified as
graph transformations
§ However more complex as with ATL
§ Graph transformations are becoming more and more relevant in
practice
§ Found their way into Eclipse!
86. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan Claypool 2012.
www.mdse-book.com
MASTERING MODEL
TRANSFORMATIONS
87. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan Claypool 2012.
HOTs
§ Transformations can be regarded as models themselves
§ They are instances of a transformation metamodel!
§ This uniformity allows reusing tools and methods defined for models
§ Thus, a transformation model can itself be created or manipulated
by transformations, by so-called Higher Order Transformations
(HOTs)
§ Transformations that take as input a model transformation and/or
generate a model transformation as output
§ Examples
§ Refactoring support for transformations to improve their internal structure
§ Adding a logging aspect to transformations
§ …
88. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan Claypool 2012.
Bi-directional Transformations
§ Bi-directional model transformation languages
§ do not impose a transformation direction when specifying a
transformation
§ allow for different execution modes such as transformation,
integration, and synchronization
§ Transformation mode is further divided into forward and
backward transformation (source - target - source)
§ Integration mode assumes to have source and target models
given and checks if expected elements (that would be produced
in the transformation mode) exist
§ Synchronization mode updates the models in case the
integration mode has reported unsatisfied correspondences
§ Languages allowing for bi-directional transformations:
§ JTL, TGG, QVT Relational, …
89. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan Claypool 2012.
Lazy Incremental Transformations
§ Standard execution strategy for out-place transformations
1) Read the complete input model
2) Produce the output model from scratch by applying all matching
transformation rules.
§ Such executions are often referred as batch transformations.
§ Two scenarios may benefit from alternative execution strategies
1) An output model already exists from a previous transformation run
for a given input model à incremental transformations
2) Only a part of the output model is needed by a consumer à lazy
transformations
§ Experimental implementations for lazy and incremental
transformations are available for ATL
90. Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan Claypool 2012.
Transformation Chains
§ Transformations may be complex processes
§ Divide and Conquer
§ Use different transformation steps to avoid having one monolithic transformation!
§ Transformation chains are the technique of choice for modeling the
orchestration of different model transformations
§ Transformation chains are defined with orchestration languages
§ Simplest form: sequential steps of transformations executions
§ More complex forms: conditional branches, loops, and further control constructs
§ Even HOTs may produce dynamically transformations used by the chain
§ Smaller transformations focusing on certain aspects allow for higher
reusability