DSMTP10ax - McGill School Of Computer Science

Download Report

Transcript DSMTP10ax - McGill School Of Computer Science

Slide 1

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 2

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 3

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 4

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 5

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 6

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 7

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 8

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 9

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 10

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 11

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 12

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 13

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 14

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 15

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 16

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 17

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 18

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 19

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 20

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 21

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 22

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 23

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 24

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 25

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 26

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 27

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 28

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 29

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 30

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 31

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 32

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 33

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 34

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 35

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 36

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 37

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 38

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 39

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 40

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 41

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 42

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 43

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 44

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 45

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 46

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 47

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 48

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 49

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 50

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 51

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 52

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 53

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 54

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 55

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 56

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 57

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 58

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 59

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 60

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 61

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 62

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 63

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 64

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 65

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 66

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 67

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 68

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 69

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 70

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 71

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 72

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 73

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 74

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 75

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 76

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 77

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 78

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 79

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 80

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 81

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 82

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 83

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 84

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 85

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 86

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 87

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 88

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 89

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 90

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 91

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 92

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 93

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 94

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 95

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 96

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 97

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 98

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 99

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 100

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 101

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 102

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 103

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 104

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 105

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 106

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 107

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108


Slide 108

Model Transformation

Eugene Syriani

and

Hans Vangheluwe

Model Transformation

Outline
1.

What is Model Transformation?
Terminology
Types of transformations

2.

A Family of Transformation Languages
Classification

3.

Rule-based Transformation
How does it work?
Tour of Existing Tools

Understanding the essence of rule-based model transformation

4.

It’s just the beginning...

2

1 What is Model Transformation?

Model Transformation

“The process of converting one model to another model of the same system.”
[OMG03]

“The automatic generation of a target model from a source model, according
to a transformation definition.”
[Kleppe03]

“A manipulation of a model with a specific intention.”
[Syriani(DSM-TP’10)]

3

In a model-driven engineering (MDE) framework

Model Transformation

• Everything is modelled
Therefore a change will always be on a model.

M

MM

MM’
conforms to

conforms to

MM

conforms to

• We explicitly model everything
A change or modification must itself be modelled  models of transformations.



M’

•  represents an intentional change (or alteration) of M, which yields M’
• MM defines all possible changes for the same intention from an instance of MM to an instance
of MM’
4

Model Transformation

Terminology

Source
Model

refers to

executes

Transformation
Definition

reads

Transformation

Target
Meta-model
conforms to

refers to

conforms to

Source
Meta-model

outputs

Target
Model

Model-to-model transformation
• Multiple sources
• Multiple targets
• The transformation can be interpreted or the result of compilation

5

Uses & Needs In Language Engineering

Model Transformation

The meta-model of a language L defines:
1. The abstract syntax of L
2. The static semantics of L
A transformation defined on L can define the dynamic semantics of L (how model instances behave)

• Denotational semantics
More specifically, translational semantics. The transformation defines a mapping between the two
formalisms.

This occurs when we transform a model in one formalism into a model in another formalism.
Then the semantics of the source formalism is given in terms of the semantics of the target
formalism.

6

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics

• Inter-formalism transformation (a.k.a. model-to-model transformation)

PhoneApps To Statecharts [Mannadiar10]

PhoneApps DSM of a conference registration mobile application

Representation of the model in Statecharts

7

Model Transformation

Uses & Needs In Language Engineering
• Denotational semantics
•

Code generation (a.k.a. model-to-code transformation)
This is a special case of model-to-model transformation.
The abstract syntax of programming languages is typically modelled by a grammar.
The abstract syntax of a program is then an abstract syntax tree.
Statecharts to Python Compiler

e

Statecharts model

if e == 0: # event “e"
if table[1] and self.isInState(1) and self.testCondition(3):
if (scheduler == self or scheduler == None) and table[1]:
self.runActionCode(4)
# output action(s1)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(1, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[1], table)
handled = 1
if table[0] and self.isInState(0) and self.testCondition(4):
if (scheduler == self or scheduler == None) and table[0]:
self.runActionCode(5)
# output action(s2)
self.runExitActionsForStates(-1)
self.clearEnteredStates()
self.changeState(0, 0)
self.runEnterActionsForStates(self.StatesEntered, 1)
self.applyMask(DigitalWatchStatechart.OrthogonalTable[0], table)
handled = 1

Generated Python code

8

Uses & Needs In Language Engineering

Model Transformation

• Operational semantics
Update the state of the system modelled.
In this case, the source and target meta-models are identical.
Moreover, the target model is an “updated” version of the source model: no new model is created

Finite State Automata Simulator

9

Uses & Needs In Language Engineering

Model Transformation

• Meta-model instance generation
Automatically generate random models that conform to the language.
This is very useful, especially for model-based testing.

Class diagram meta-model

10

Uses & Needs In Language Engineering

Model Transformation

• Relation between Abstract and Concrete syntax
Model transformation can be used to specify mappings within the language too.
It can be used only if both the abstract and concrete syntax are themselves modelled.

• Mapping from the abstract syntax to possibly several concrete representations
(textual, graphical, ...)
 1 abstract syntax to many concrete syntaxes
• Parser from the concrete syntax to the corresponding abstract syntax (graph)
 1 concrete syntax to 1 abstract syntax

11

Types of transformations

Model Transformation

A model transformation performs a manipulation on a model.
• Access/Modify operations
• Simple operations on a model:
•

Add an element to the model;

•

Remove an element from the model;

•

Update an element’s properties;

•

Access an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

12

Types of transformations

Model Transformation

• Query
A query is still a transformation.
• What is a query?

• A query is an operation that requests some information about a system.
• This operation takes as input the model M and outputs a view of M.
• A view is a projection of (a sub-set of) the properties of M.
• Restrictive view: Reveal a subset of the properties of M (all, none, some)
•

Retrieve all cycles in a causal block diagram

•

Show only classes/associations of a class diagram

• Aggregated view: Restriction of M modifying some of its properties
•

Get the average of all costs per catalogue product in a relational database schema

•

In a hierarchical model, show top-level elements only, with an extra attribute denoting the
number of sub-elements

 Is a query a transformation?
• It is a projection, obtained by CRUD operations on the properties of M.
13

Model Transformation

Types of transformations
• Query
• Different views for different observers
•

Views must be kept consistent with the repository

•

This can be ensured by a model transformation that defines a relation between the repository and a view
[Guerra06]

•

Read-only views: propagate any changes from repository to all views (or some of them)

•

Write-enabled views: propagate changes from a modified view to the repository, which will propagate the changes to the other
views

•

This is called model synchronization

Repository

14

Types of transformations

Model Transformation

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

Source code translated into machine code

•

Design models translated into source code

15

Model Transformation

Types of transformations

• Common Uses of Model Transformation (inspiration from [Mens06])
• Synthesis
Transform from a higher level specification to a lower level description
•

Code Generation

•

DSM compiled into an executable implementation

PhoneApps DSM of a conference registration mobile application

Generated AndroidAppsFiles

16

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones
•

C# to UML Class Diagram

17

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Reverse Engineering
Inverse of synthesis: extract higher-level specifications from lower-level ones

• If the same model transformation T synthesizes M1 into M2 and reverse engineers M2 to M1,
then T is said to be a bi-directional transformation.

Statechart representing a conference registration model

PhoneApps DSM of the same model

18

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Simulation
• Update the state of the model

• Operational semantics

19

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Migration
Transform from a software model written in one language or framework into another, but keeping
the same level of abstraction.
•

Evolution to new version

Enterprise Java Beans 2.0

Enterprise Java Beans 3.0
20

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models
SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

+cells

Dictionary
Mapping

1

«struct»
Coordinate

*

+key 1

+value *
SSheetCell

List to table optimization

-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

SSheet
+
+
+
+
+

addRow() : void
addColumn() : void
1
getCell(Coordinate) : SSheetCell
getCellValue(Coordinate) : CellValue
setCellValue(SSheetCell, CellValue) : void

2DArray

+cells

+items

1

* -

+value 1

SSheetCell
-

coordinate: Coordinate

+
+

getValue() : CellValue
setValue(CellValue) : void

2DItem
index: int

+value
1

Item
-

index: int

+items

Array

*

«struct»
Coordinate
-

row: int
column: int

+
+
+

set(int, int) : void
row() : int
col() : int

21

Types of transformations

Model Transformation

• Common Uses of Model Transformation
• Restructuring
Change the internal structure of the model to improve certain quality characteristics without
changing its observable behaviour
(Understandability, modifiability, reusability, modularity, adaptability)
•

Refactoring: restructuring in an object-oriented context

Pull up method refactoring

22

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Normalization
Decrease syntactic complexity
•

Desugaring: Translate complex language constructs (syntactic sugar) into more primitive language constructs

•

Simplification: Transform all uses of a language construct in a normal or canonical form

CH3

CH2

OH

H

H

H

C

C

H

H

O

H

• Map the concrete syntax back to the abstract syntax
23

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Composition
Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

24

Model Transformation

Types of transformations
• Common Uses of Model Transformation
• Synchronization

Integrate models that have evolved in isolation but that are subject to global consistency
constraints
• In contrast with composition, synchronization requires that changes are propagated to the
models that are being integrated
• Source model changes are propagated to corresponding target model changes:
Incremental / Change-driven transformation.

• Synchronization must be ensured in both directions: multi-directional transformation.
• Inconsistency management

Repository

25

Classification of the types of transformations

Model Transformation

• Relationship between source & target meta-models
• Endogenous: Source meta-model = Target meta-model
• Exogenous: Source meta-model ≠ Target meta-model

• Relationship between source & target models
• In-place: Transformation executed within the same model
• Out-place: Transformation produces a different model

Endogenous

Exogenous

Either

In-place

Access/Modify, Simulation

X

X

Out-place

Restrictive query,
Simplification

Aggregate query, Synthesis,
Reverse engineering,
Migration, Desugaring

Composition, Synchronization

Either

Optimization, Restructuring

X

X

26

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Abstraction level
• Horizontal: source and target models reside at the same abstraction level.

• Vertical: source and target models reside at different abstraction levels

Horizontal

Vertical

Endogenous

Exogenous

Either

Access/Modify, Simulation,
API migration

Language migration

Composition

Aggregate query,
Synthesis, Reverse
engineering, Desugaring

X

Formal refinement,
Restructuring,
Restrictive query,
Optimization, Simplification

27

Classification of the types of transformations

Model Transformation

Classification of the types of transformations
• What about composition?
• It is certainly out-place, but it also depends if:
•

Merging different views of the same repository

•

Interoperating with other languages

•

Merging an old version of the model with a newer one

• What about synchronization?
• It is orthogonal to the other types
• It is certainly out-place
• You can synchronize any two models as long as you give it a precise meaning.
•

Synthesis + reverse-engineering (in loop)

•

Refactoring or migration (if retaining snapshots of all versions)

28

Model Transformation

Classification of the types of transformations
Classification of the types of transformations
• Syntactical vs. Semantical Transformations

• A syntactical transformation solely modifies the representation of the model

• In a semantical transformation, the output model has a different meaning than the
input model, although the representation of the latter may or may not have been
modified.
Syntactical

Query

Synthesis

Reverse
Engineering

Simplification

Desugaring

-

-

Semantical

Access /
Modify

Simulation

Migration

Optimization

Restructuring

Composition

Synchronization

Model transformation chain to compile a DSM into executable Java code
refactor/optimize

DSM
in CS

parse

ASG

synthesize

Code

ASG’

29

2 Family of Transformation Languages

Model Transformation

Model Transformation has many applications:
• Generate PSMs form PIMs and reverse engineering
• Map and synchronize among models at the same or different level of abstraction

• Create views of a system
• Model evolution tasks

• Since the applications are very different in nature, it is not optimal to have a single
model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to
specific transformation problems.
• We will now explore all the features that a model transformation language can have.
• It covers more than what current tools support but this framework may change
because of the very active research in the field.

30

Family of Transformation Languages

Model Transformation

• Feature diagram [Kang90]
• Hierarchy of common and variable features characterizing the set of instances of a
concept.
• Tree-like structure where each combination of the leaves yields one possible instance
of the concept.

• (sub-set of) Elements of a Feature Diagram
•

Root: Concept

•

Mandatory sub-feature: parent feature cannot exist without sub-feature

•

Optional sub-feature: sub-feature may or may not be present

•

Sub-features: by default OR

•

Alternative sub-features: XOR

•

Group: typical features, does not cover all possibilities

•

Leaf: primitive feature, but maybe split in further sub-feature
at a later stage
31

Family of Transformation Languages

Model Transformation

• Feature diagram
• Example:

32

Family of Transformation Languages

Model Transformation

• Features of model transformation languages [Czarnecki06]

• Specification
Pre/post condition on the transformation:
• Function between source & target models
• Relation may be executable or not

• Transformation Rules
Smallest transformation unit, used to specify a transformation
• Rule-based transformations: pre-condition & post-condition for
rewriting
• Transformation units defined as functions
• Templates

•

•

Rule Application Control

• Where is a rule applied on the model
• In what order are the rules executed

Source-Target Relationship

• In-place
• Out-place

• Rule Organization
General structuring issues of rules
• Modularization
• Composition
• Re-use

• Incrementality
Ability to update existing target models based on changes in
the source models
• Directionality
Transformation executed in one direction or in multiple directions
(uni-/multi-directional transformation)
• Tracing
Mechanisms for recording different aspects of transformation
execution:

• Create & maintain trace links between source & target model elements

33

Family of Transformation Languages

Model Transformation

• Transformation Rules
• Smallest transformation units
• A model transformation is mainly specified in terms of rules

:

:

34

Model Transformation

Family of Transformation Languages
• Domain

• Defines how a rule can access elements of the models
• 1..* domains: examples of 1-way transformation? 2-way? n-way?
• Domain language
•

The language in which models are defined. Typically MOF [OMG06]

• Modes
•

Read-only: source domain of synthesis

•

Write-only: target domain of synthesis

•

Read-write: domain of simulation

QVT-Relations rule [OMG08]
top relation PackageToSchema {
domain uml p:Package {name = pn}
domain rdbms s:Schema {name = pn}
}
35

Family of Transformation Languages

Model Transformation

• Domain Body

• Patterns
Model fragment internally represented as:
•

Strings: Template-based transformation

•

Terms: tree representation of models

•

Graph: Model-to-model transformation

36

Model Transformation

Family of Transformation Languages
• Domain Body

• Logic
How computations & constraints are specified on model elements

Imperative

Declarative

Executable

Java API for MOF
models

OCL query

Non-executable

X

QVT-R relation

37

Family of Transformation Languages

Model Transformation

• Domain Body

• Logic
Declarative vs. Imperative

QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package{name=pn}
domain rdbms s:Schema{name=pn}
}

Kermeta operation [Falleri06]
operation transform(source:PackageHierarchy): DataBase is do
result := DataBase.new
trace.initStep(“uml2db”)
source.hierarchy.each{ pkg |
var scm: Schema init Schema.new
scm.name := String.clone(pkg.name)
result.schema.add(scm)
trace.addlink(“uml2db”, “package2schema", pkg, scm)
}
end
38

Family of Transformation Languages

Model Transformation

• Domain of Rule

• Typing

of variables, patterns, and logic
•

Untyped: free text / free hand drawing

•

Syntactical typing: variable is associated with
a meta-model element & can hold its instances

•

Semantical typing:

•

•

Static semantics: well-formed rules

•

Dynamic semantics: behavioural properties
(DSLTrans)

Example of type system: Ensure the output of a rule
will satisfy certain properties, if the input model
satisfies some properties.

FUJABA [Fischer00] transformation pattern

39

Model Transformation

Family of Transformation Languages

• Syntactic Separation
Clear separation of parts of the rule operating on the source model from the parts operating on
the target model.

MoTif [Syriani09a] rule

FUJABA: compact notation

module Person2Contact;
create OUT: MMb from IN: MMa {

ATL rule

rule Start {
form p: MMa!Person(
p.function = ‘Boss’
)
to c: MMb!Contact(
name <- p.first_name + p.last_name)
}

40

Family of Transformation Languages

Model Transformation

• Multi-directionality
Ability to execute a rule in different directions.
E.g., QVT-R and Triple Graph Grammar (TGG) [Schurr94]

TGG rule
QVT-Relations rule
top relation PackageToSchema {
domain uml p:Package {name = n}
domain rdbms s:Schema {name = n}
}

41

Family of Transformation Languages

• Application Conditions
Pre-condition for the rule before it is executed
•

QVT-R: when clause

•

AToM3: rule-level constraint [Lara02]

Model Transformation

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
name = cn
}
domain rdbms t:Table {
schema = s:Schema{},
name = cn,
cols = cl:Column {
name = cn + ‘_tid’,
type = ‘NUMBER’},
pkey = cl
}
when {
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
}

42

Model Transformation

Family of Transformation Languages

• Intermediate Structures
Creation of additional elements which are not part of the domain
•

AToM3: generic links

•

ATL: automatic creation of traceability links.
Each newly created element is linked back to element(s) of the source model.

•

AGG [Taentzer04] and VIATRA [Varro07]: make use of traceability to prevent a rule from being applied on
the same element.

MoTif rule

43

Family of Transformation Languages

Model Transformation

• Parameterization
• Control Parameters
Pre-defined binding of some model elements
•

ProGreS: variable parameter passing [Zundorf94]

•

GReAT: pivot nodes [Agrawal06]

ProGreS in/out parameters

GReAT pivot passing

44

Family of Transformation Languages

Model Transformation

• Parameterization
• Generics
•

Pass element types to rules

•

In this case, the types of the elements in the patterns are variable

• Higher-Order Transformation Rule
Takes a rule as input and outputs another rule
(see “Higher-Order Transformation” lecture)

VIATRA generic rule
45

Family of Transformation Languages

Model Transformation

• Location Determination
Strategy for determining the application locations of a rule

Model:

Rule:

46

Model Transformation

Family of Transformation Languages
• Rule Scheduling

• Form
• Implicit: completely determined by the design logic of the rules
•

Unordered: One rule that is applicable is selected to be applied non-deterministically at each iteration

•

Grammar: unordered with start model and terminal states (generation or recognition)

• Some GT languages with implicit scheduling: Groove [Rensink04], MOMENT2 [Boronat10]

Rules:

,

Model:

47

Family of Transformation Languages

Model Transformation

• Rule Scheduling

•
•
•
•

top relation ClassToTable {
domain uml c:Class {
package = p:Package{},
isPersistent = true,
Form
name = cn
}
Explicit internal: a rule may invoke other rules.
domain rdbms t:Table {
schema = s:Schema{},
In ATL [Jouault08], a matched rule (implicitly scheduled) may
name = cn,
invoke a called rule in its imperative part. Lazy rules
cols = cl:Column {
name = cn + ‘_tid’,
In QVT, the when/where clauses of a rule may have a reference to
type = ‘NUMBER’},
pkey = cl
other rules.
}
When: the former will be applied after the latter.
when {
Where: the latter will be applied after the former.
PackageToSchema (p, s);
}
where {
AttributeToColumn (c, t);
}
48
}

Family of Transformation Languages

Model Transformation

• Rule Scheduling

• Form
• Explicit external: Clear separation between the rules and the scheduling logic.
Use a control structure to define rule scheduling

• Ordered: priority, layer/phased, explicit workflow structure, …
• Event-driven: rule execution is triggered by external events

49

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Priority-based: AToM3

50

Family of Transformation Languages

Model Transformation

• Rule Scheduling
Layered/Phased: AGG

51

Model Transformation

Family of Transformation Languages
• Rule Scheduling
Explicit workflow

GReAT data flow

FUJABA story diagram

52

Model Transformation

Family of Transformation Languages
• Explicit Scheduling features [Syriani09]

VMTS

PRoGReS

FUJABA

VIATRA

AToM3

GReAT

Control
structure

Imperative
language

Story Diagram

Abstract state
machine

Priority
ordering

Data flow

Activity
diagram

DEVS

Atomicity

transaction,
rule

Rule

gtrule

Rule

Expression

Step

ARule

Sequencing

&

Yes

seq

Implicit

Yes

Yes

Yes

Branching

choose...else

Branch activity

if-then-else

No

Test / Case

Decision step,
OCL

Query

Looping

loop

For-all pattern

iterate, forall

Implicit

Yes

Self loop

FRule, SRule,
LRule

Nondeterminism

and, or

No

random

Within layer

No

Selector
pattern

Recursion

Yes

No

Yes

No

Yes

Yes

Yes

Parallelism

No

Optional

No

Optional

No

Fork, Join

Synchronizer
pattern

Backtracking

Implicit

No

choose
(implicit)

No

No

No

XRule

Hierarchy

Modularisation

Nested state

Yes

No

Block,
ForBlock

High-level
step

CRule

1−n

connection

[Lengyel06]

MoTif

53

Family of Transformation Languages

Model Transformation

• Explicit Scheduling features
What these languages/tools have in common:
• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:
• AGG: layered graph transformation
• MOLA [Kalnins05]: structured flowchart
• T-Core [Syriani10]: primitive graph transformation operators combined with Python
• DSLTrans: ...
• and many more
• Non GT languages with explicit control structure: QVT-Operational Mappings, Kermeta

54

Family of Transformation Languages

Model Transformation

• Rule Organization
• Modularization: Package rules into modules.
•

Module imports (QVT, VIATRA, ATL)

• Reuse: Define rules based on other rules.
•

QVT specification presents very sophisticated reuse mechanisms, but no implementation of it.

•

ATL allows a rule to inherit from another rule: union of pre-conditions and bindings.

55

Family of Transformation Languages

Model Transformation

• Source-Target relationship
• Graph transformation approaches are in-place by construction
• ATL is out-place only.
• QVT allows creating a new model or updating an existing one.

• Extension Only updates: an existing element (source or already created) may not be deleted
• Destructive update: emulates out-place transformations by first creating new elements and then
deleting source model elements

56

Family of Transformation Languages

Model Transformation

• Incrementality
• An incremental transformation is defined as a set of relations between a source and target metamodels. These relations define constraints on models to be synchronized.
• The first time it is run, it creates a target model. Trace links are often automatically created.
• Then, if a change is detected in one of the models, it propagates this change to the other model, by
adding, removing, or updating an element so that the relations are still satisfied.

• There are 4 standard scenarios in model synchronization:
•

Create a target model from the source model

•

Propagate changes in the source model to the target model

•

Propagate changes in the target model to the source model

•

Verify consistency between the two models

57

Family of Transformation Languages

Model Transformation

• Directionality
• Unidirectional : create (or update) the target model only
• Multi-directional: can be executed in any direction
• Need multi-directional rules
• Define separate unidirectional rules, one for each direction

• Operational rules have a functional character: given an input model, produce a target model.
 Causality from source to target model

• Declarative rules: gives a relation between both models that must be satisfied
 Acausal relationship between the models

58

Family of Transformation Languages
• TGG rules are bi-directional

Model Transformation

TGG operational rules

• The denotational rules are converted into operational rules:
TGG rule

One TGG rule generates 7 TGG operational rules:
• Every new element in a model has a correspondence in the other [x2]
• When an element is removed from a model, its correspondent
element(s) is (are) deleted appropriately [x2]
• Enforce the consistency relations between attributes [x2]
• Create a correspondence between unmapped elements of the two
models [x1]
59

Family of Transformation Languages

Model Transformation

• Tracing

is the runtime footprint of a transformation execution

• Traceability links connect source & target elements
They are instances of the mappings between the domains
• Impact analysis
• Direction of the synchronization
• Debugging transformations
• Automatic creation of trace links: QVT, ATL
• Traces can be considered as any other model, but has to be manually created:
e.g., AGG, AToM3, VIATRA
60

Different Model Transformation Approaches

Model Transformation

• Model-to-text (concrete syntax)
• Visitor-based: traverse the model in an object-oriented framework
• Template-based: target syntax with meta-code to access source model

• Model-to-Model
• Direct manipulation: access to the API of M3 and modify the models directly
• Operational: similar to direct manipulation but at the model-level (OCL)
• Rule-based
•

Graph transformation: [Ehrig97] implements directly the theory of graph transformation, where
models are represented as typed, attributed, labelled, graphs in category theory. It is a declarative way of
describing operations on models.

•

Relational: declarative describing mathematical relations. It define constraints relating source and target
elements that need to be solved. They are naturally multi-directional, but in-place transformation is
harder to achieve

61

3 Rule-based Transformation

Model Transformation

• By Example:
Simplified PacMan formalism [Heckel06]

62

Rule-based Transformation

Model Transformation

• Build the meta-model of the PacMan formalism in AToM3

63

Rule-based Transformation

Model Transformation

• Build the graph transformation to specify the semantics of the language

64

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language
pacLink

5
1

P1

1

4
3

2

2

ghostLink

3

ghostLink

1
4

2

6

1

5

4

2

pacLink

pacLink

3
foodLink

P2

3
1:

return self.LHS.nodeWithLabel(1).score + 1

65

Model Transformation

Rule-based Transformation

• Build the graph transformation to specify the semantics of the language

ghostLink

ghostLink

1
5

2

1

2

3
gridLeft

4

gridLeft

pacLink
pacLink

2

5

P3

1

2

6

3
4

P3

3
4

1

6

gridRight

3
4

gridRight

66

Rule-based Transformation

Model Transformation

• Simulation of a model

P1

1. pacmanDie

P2 2. pacmanEat
P3

3. ghostMoveLeft
4. ghostMoveRight
5. ghostMoveUp
6. ghostMoveDown
7. pacmanMoveLeft
8. pacmanMoveRight
9. pacmanMoveUp

10. pacmanMoveDown

67

Model Transformation

Rule-based Transformation
• Mechanics of Rule Application

L

K

R

gLink

gLink
right

right

m
gLink right

right

left
up

down

left
up

down

up

right

pLink

left

G

gLink

down

up

down

right

fLink

pLink

left

fLink

G’

If there exists an occurrence of L in G then replace it with R
68

Model Transformation

Rule-based Transformation
Mechanics of Rule Application
• Matching Phase
• Find an embedding (m) of the LHS pattern (L) in the host graph (G).
• An occurrence of L is called a match:
• Thus,

m(L).

m(L) is a sub-graph of G.

• Rewriting Phase
Transform

G so that it satisfies the RHS pattern:

1. Remove all elements from

m(L-K)

2. Create the new elements of

from

R-K in G.

3. Update the properties of the elements in
•
•

G.

m(L  K).

When a match of the LHS can be found in G, the rule is applicable.
When the rewriting phase has been performed, the rule was successfully applied.
69

Rule-based Transformation

Model Transformation

• How to find a match?
• The matching phase is NP-Complete, the rewriting phase is linear.
• There are various exponential-time worst case solutions for pattern matching, for
which the average-time complexity can be reduced with the help of heuristics.
• Search Plan Approach
• Define the traversal order for the nodes of the model to check whether the LHS can be
matched.

• Compute the cost tree of the different search paths and choosing the less costly one.
• Complex model-specific optimization steps can be carried out for generating efficient
adaptive search plans.
• Constraint Satisfaction Solving Approach
• Consider the LHS elements as variables, the elements of model form the domain and
typing, and the links and attribute values form the set of constraints.
• Based on back-tracking algorithms.

70

Rule-based Transformation

Model Transformation

Complexity of a rule
What is the worst upper-bound of the complexity for applying a rule?



O(|L||G| + |R|) = O(|L||G|) CRUD operations

71

Model Transformation

Most Used Rule-based Transformation Tools
• Programmed Graph Rewriting System: ProGReS

Manfred Nagl

Andy Schürr

Albert Zündorf

University of Aachen (Germany)
1988-1999

72

Most Used Rule-based Transformation Tools

Model Transformation

• Programmed Graph Rewriting System: ProGReS

73

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

Universities of Paderborn, Kassel, Darmstadt, Bayreuth (Germany)
Since 1998

74

Most Used Rule-based Transformation Tools

Model Transformation

• From UML to JAVA And Back Again: FUJABA

75

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

University of Darmstadt (Germany)
Since 2004

76

Most Used Rule-based Transformation Tools

Model Transformation

• MOFLON

77

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

Gabor Karsai

Aditya Agrawal

Vanderbilt University, Nashville (USA)
Since 2001

78

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: GReAT

79

Model Transformation

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Tihamér Levendovszky

VMTS

László Lengyel

Budapest University of Technology and Economics (Hungary)
Since 2004
80

Most Used Rule-based Transformation Tools
• Visual Modelling and Transformation System:

Model Transformation

VMTS

81

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

Dániel Varró

Budapest University of Technology and Economics (Hungary)
Since 2002, VIATRA2 since 2006

82

Most Used Rule-based Transformation Tools

Model Transformation

• Graph Rewriting and Transformation: VIATRA

83

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

Jean Bézivin

Frédéric Jouault

École des Mines de Nantes (France)
Since 2005
84

Most Used Rule-based Transformation Tools

Model Transformation

• ATLAS Transformation Language: ATL

85

Primitive Transformation Operations

Model Transformation

What is common to the different rule-based transformation approaches?
• Pre-/Post- condition patterns
• Matching

• Rewriting
• Validation of consistent rule application
• Matches manipulation
• Iteration
• Roll-back
• Control flow
• Choice
• Concurrency
• Composition

86

Primitive Transformation Operations

Model Transformation

T-Core Module [Syriani10]

• Pattern representation
• Matches processed structure

• 8 primitive transformation
operators

87

Primitive Transformation Operations

Model Transformation

T-Core Module

Dissociate pre- from post-condition
patterns
‒ Query vs. Rule
‒ Embedded inside Matcher &
Rewriter

88

Primitive Transformation Operations

Model Transformation

T-Core Module

Packet
‒ Host graph
• MatchSet
‒ Matches for a given pattern
• Match
‒ Sub-model of interest
• Pivot
‒ Node binding (across match sets)
‒ Parameterized rule

89

Primitive Transformation Operations

Model Transformation

T-Core Module
• Dissociate Match from Rewrite:
‒ match-rewrite- match-rewrite
‒ match-match-match
‒ match-match-rewrite-rewrite
• Matcher
‒ Find one, max, all (parameter)
‒ Store matches in packet
• Rewriter
‒ Apply rewriting phase
‒ Consume matches
• Resolver
‒ Conservative check of conflicts
among match sets
‒ Customizable resolution function

90

Primitive Transformation Operations

Model Transformation

T-Core Module

• Iterator
‒ Randomly choose a match in a
match set
‒ Number of iterations
• Rollbacker
‒ Ensure transactional behaviour
‒ Restore packet when all matches
exhausted
‒ Number of iterations
• Combine to handle multiple
matches

91

Primitive Transformation Operations

Model Transformation

T-Core Module

• Selector
‒ Can store packets
‒ Select one on demand
• Synchronizer
‒ Can store packets
‒ Merge packets on demand
‒ Customizable merge function

92

Primitive Transformation Operations

Model Transformation

T-Core Module

• Meaningfully compose its subprimitives
• User-defined composition
• Common interface

93

Primitive Transformation Operations

Model Transformation

Primitive transformation operators
(sub-set of) T-Core module

+
Scheduling language
 Programming language (Python, Java)
 Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)


Transformation Language

94

Primitive Transformation Operations

Model Transformation

• There are many transformation languages and tools out there.
• They are very good at what they do.
• Also, most of them tend to provide a generic tool to solve any kind of model
transformation problem.
• Because of the high amount of expressiveness, analysis of transformation models built
using these general purpose transformation is very hard.
• Providing control over T-Core primitives allows to restrict a transformation language
for one specific purpose.
• It depends on the expressiveness of the glue language used and the primitive
operators chosen.

95

Primitive Transformation Operations

Model Transformation

96

Primitive Transformation Operations

Model Transformation

Query

97

Primitive Transformation Operations

Model Transformation

Atomic Rule

98

Primitive Transformation Operations

Model Transformation

Rule applied as long as possible

99

Primitive Transformation Operations

Model Transformation

Combining rules with Python

100

4 What is Required for Industrial Adoption?

Model Transformation

• Scalability
• Size of source model
• How big of a model can be handled: 103, 105, 106 elements?
• Size of transformation

• Size of the total sequence of rules applied
• Number of rules evaluated at a given point ?
• Interoperability
• Treat transformations as black-boxes but ensure the communcation between them

• Common formalism acting as a “bus”

• Expressiveness
• Pattern language

• Scheduling language
• Reversibility / Bidirectionality
• Handle arbitrarily complex attribute constraints

101

What is Required for Industrial Adoption?

Model Transformation

• Analysis
• Model Checking
• Input & output model
• Transformation model
• Verification
• Transformation: correct application, property satisfaction
• Rules: parallel independence

• Testing
• Adequate test input
•

How to assess quality of models?

• Adequate design of oracle
•

Generic?

•

Domain specific?

•

Transformation specific?

102

What is Required for Industrial Adoption?

Model Transformation

• Debugging
•

Transformation

•

Appropriate support for user to determine origin of failure

•

Generated Artefacts

•

Debug in terms of output model (or input model)

• Profiling
•

Time efficiency

•

Profile results in terms of transformations, domain-specific

• Traceability
•

Trace back to origin of error

•

Trace back to which element the created/modified element originated form

• Evolution
•

Of the languages

•

Of the transformations

103

Making a Well-Informed Choice

Model Transformation

• Commercial point of view
• Evaluate a tool
• Types of transformations supported

• Transformation class
• Supported features
• Be up-to-date with recent innovations

• Research point of view
• What is still open for research
• Be aware of what has been solved

• Challenges

104

References

Model Transformation

[OMG03] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.
[Kleppe03] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And
Promise. Addison-Wesley, 2003.
[Mannadiar10] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from DomainSpecific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.
[Mens06] Mens, T. & Van Gorp, P. A Taxonomy of Model Transformation. GraMoT'05, ENTCS: 152, pp. 125-142
Tallinn (Estonia), March 2006.
[Guerra06] Guerra, E. & de Lara, J. Model View Management with Triple Graph Transformation Systems. ICGT'06,
LNCS: 4178, pp. 351-366, Springer-Verlag, 2006.

[Kang90] Kang, K. C.; Cohen, S. G. ; Hess, J. A.; Nowak, W. E. & Peterson, A. S. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90- TR-21, Software Engineering Institute,
Carnegie Mellon University, November 1990.
[Czarnecki06] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems
Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

[OMG06] Object Management Group (OMG). Meta Object Facility 2.0 Core Specification. January 2006 .
[OMG08] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.
[Fischer00] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based
on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764,
pp. 296-309, Springer-Verlag. Paderborn (Germany), November 2000.

105

References

Model Transformation

[Falleri06] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in
Kermeta. ECMDA-TW'06, pp. 31-40 , HAL-CCSd-CNRS. Bilbao (Spain), July 2006.
[Schurr94] Schürr, A. Specification of Graph Translators with Triple Graph Grammars. Graph-Theoretic Concepts in
Computer Science, LNCS: 903, pp. 151-163 , Springer-Verlag. Heidelberg (Germany), June 1994.
[Lara02] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS:
2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.
[Taentzer04] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software.
AGTIVE'03, LNCS: 3062, pp. 446-453 , Springer-Verlag, 2004 .
[Varro07] Varró, D. & Balogh, A. The model transformation language of the VIATRA2 framework. Science of
Computer Programming, 68, no. 3, pp. 214-234 , Elsevier North-Holland, 2007.
[Zundorf94] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer
Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.
[Agrawal06] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for
Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.

[Rensink04] Rensink, A. The GROOVE Simulator: A Tool for State Space Generation. AGTIVE'03, LNCS: 3062, pp.
479-485 , Springer-Verlag, 2004.
[Boronat10] Boronat, A. & Ölveczky, P. Formal Real-Time Model Transformations in MOMENT2. Fundamental
Approaches to Software Engineering, LNCS: 6013, pp. 29-43 , Springer, 2010.
[Jouault08] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer
Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.
106

References

Model Transformation

[Ehrig97] Ehrig, H.; Engels, G.; Kreowski, H.-J. & Rozenberg, G. Handbook of graph grammars and computing by
graph transformation, Volume 1: Foundations. World Scientific Publishing, 1997.
[Syriani09] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2,
School of Computer Science, March 2009.
[Lengyel06] Lengyel, L.; Levendovszky, T.; Mezei, G. & Charaf, H. Model Transformation with a Visual Control Flow
Language. IJCS, 1, no. 1, pp. 45-53, 2006.
[Syriani09a] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In:
Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC
Press. Boca Raton (USA), 2009.
[Kalnins05] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS:
3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.
[Syriani10] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29
(GT-VMT'10), Paphos (Cyprus), March 2010.
[Heckel06] Heckel, R. Graph Transformation in a Nutshell. FoVMT '04, ENTCS: 148, no. 1, pp. 187-198, Elsevier
2006.

107

Additional References

Model Transformation

• The following web page offers around 240 literature citations in the field of model
transformation
• It provides more details in each topic outlined in this talk and more

http://msdl.cs.mcgill.ca/people/eugene/30_litterature

108