Model Transformation: A survey of the state of the art

©TomMens,Umons,2009
InternationalSchoolMDD4DRES,Aussois
2
Antoine-Laurent de Lavoisier
(1743-1794)
"Rien ne se perd, rien ne se
crée, tout se transforme."
"Nothing is lost, nothing is
created, all is transformed.”

3
Model-Driven Engineering (MDE)
•  An approach to software development where
the principal artefacts are models (as opposed
to code)
•  Why?
– To reduce the accidental complexity
of software
•  caused by the technology or methods
used to solve the problem
– As opposed to essential complexity
•  Inherent to the problem, cannot be
reduced by any technology or language

4
Model-Driven Engineering
•  Basic Principle: « Everything is a model »
– Allows us to use a generic approach, applicable to any kind of
software artefact
– Even source code can be considered to be a model
– modeling languages can be represented as models too
•  The technique of « model transformation » is
crucial to be able to manipulate software
models

5
state of the
practice
state of the
art
Model-Driven Engineering
Code
Level of automation
Abstraction level
code
only
code
centric
Code Code Code
Model Model Model Model
round-trip
engineering
model
centric
executable
models
visualise synchronise generate

6
Model Transformation
•  Many purposes and uses
– Automatic code generation
– Synthesising models from code (e.g. program
comprehension)
– Evolving models (e.g. model quality improvement)
– Model simulation, execution and animation
– Model checking, verification and analysis
– Model quality improvement
– Model translation
– Test generation
– Model merging
– Model weaving
– Model (de)composition
– Model-based testing
– …

7
Model Transformation Support
•  In order to provide automated support for model
transformation, we need
– Formal methods
– Standards
– Methodologies / Processes
– Tools
– Transformation languages

8
•  Needs formal methods
– For model analysis and verification, model checking,
model transformation correctness, …
•  Needs standards
– UML, XMI, QVT, SysML,
EMF, Ecore, …
•  Needs methodologies
– RUP, Executable UML (based on the
method Schlaer-Mellor)

9
•  Needs tools
– AndoMDA
– Rational Technical Developer (IBM)
(f.k.a. Rational Rose RealTime)
– Telelogic Tau (IBM)
(f.k.a. Rhapsody)
– Together Architect (Borland)
– OptimalJ (Compuware)
– Mathworks Simulink
– Codagen Architect
– ATLAS
– Kermeta
– …

10
•  Needs transformation languages
– ATL (ATLAS Transformation Language)
– Kermeta
– QVT
– VIATRA2
– GReAT
– AGG
– ATOM3
– Fujaba
– MOFLON
– Tefkat
– SiTra
– …

11
A Taxonomy
•  Another dimension: modeling level
– Example: OMG’s 4-level modeling architecture
meta-model
model
“the real world”
meta-meta
model
MOF: a unique meta-metamodel
Metamodels
(e.g. UML modeling language)
Software models
(e.g. UML diagrams)
Real-world being modeled
(e.g. running software systems)
M0
M1
M2
M3

Model transformation languages

13
A Taxonomy
•  Transformations can be classified along
different axes
– Endogenous versus exogenous transformation
•  Endogenous transformations transform source model(s) into
target model(s) expressed with same metamodel
•  Exogenous transformations transform source model(s) into
target model(s) expressed with different metamodels
– Horizontal versus vertical transformation
•  Horizontal transformations are expressed between models
residing at the same abstraction level
•  Vertical transformations are expressed between models at
different levels of abstraction
(e.g. requirements -> design, design -> code)

14
A Taxonomy
•  Two orthogonal dimensions
– Examples
endogenous exogenous
horizontal model quality
improvement
language translation
(e.g. UML to XMI,
UML to ER)
vertical refinement code generation,
model synthesis

15
Model Transformation Languages
A Taxonomy
•  Transformation languages can be classified
along different axes
– Declarative versus operational languages
– Text-based versus visual languages
– Ad-hoc versus formally founded
– General-purpose versus domain-specific

16
A Taxonomy
•  Declarative versus operational languages
– Operational / Imperative languages
•  ATL (ATLAS Transformation Language), INRIA France
– Part of Eclipse M2M (Model to Model) project
•  Kermeta, IRISA Rennes
•  SiTra (University of Kent)
•  QVT Operational
– Supported by various tools (e.g. mediniQVT, ModelMorf)
– Declarative / Relational languages
•  QVT Relational, OMG
– Supported by various tools (e.g. Borland Together)
•  Tefkat
•  Various languages based on graph transformation
– VIATRA2, GReAT, AGG, ATOM3, Fujaba, MOFLON

17
A Taxonomy
Text-based languages
•  ATL
•  Kermeta
•  Tefkat
•  SiTra
•  QVT Operational
•  QVT Relational
Visual languages
•  GReAT
•  VIATRA2
•  AGG
•  ATOM3
•  Fujaba
•  MOFLON
•  QVT Relational

18
module Replace;
create OUT : KM3 from IN : KM3;
rule Metamodel {
from inputMm:KM3!Metamodel
to outputMm:KM3!Metamodel ( location <- inputMm.location, contents <- inputMm.contents ) }
rule Package {
from inputPkg:KM3!Package
to outputPkg:KM3!Package ( name <- inputPkg.name, contents <- inputPkg.contents ) }
rule ClassA {
from inputA:KM3!Class ( inputA.supertypes.isEmpty() )
to outputA:KM3!Class ( name <- inputA.name, isAbstract <- inputA.isAbstract ) }
Example
•  A model transformation in ATL
– Replace inheritance by aggregation in a class
diagram, part 1 textual and
procedural

19
rule ClassB {
from inputB:KM3!Class ( not(inputB.supertypes.isEmpty()) )
to outputB:KM3!Class (name <- inputB.name, isAbstract <- inputB.isAbstract,
structuralFeatures <- inputB.supertypes
->iterate(a;acc : Sequence(KM3!StructuralFeature) = Sequence{}|
acc->including(thisModule.Inherit2Association(a,inputB)) ) ) }
lazy rule Inherit2Association {
from supertype:KM3!Class, children:KM3!Class
to refChildren : KM3!Reference ( name <- 'inherit'+supertype.name, opposite <- refSupertype,
owner <- children, type <- supertype, lower <- 1, upper <- 1 ),
refSupertype : KM3!Reference( name <- 'children'+children.name, opposite <- refChildren,
owner <- supertype, type <- children, lower <- 1, upper <- 1 ) }
Example
•  A model transformation in ATL
– Replace inheritance by aggregation in a class
diagram, part 2 textual and
procedural

20
Example
•  A model transformation in Fujaba
– Pull up method in a class diagram
visual and
declarative
based on
control flow

21
Example
•  A model transformation in GReAT
– Generation of Sierpinski triangles
visual and
declarative
based on
data flow

22
Example
•  A model transformation in QVT Relational
– UML class to relational database schema
•  Graphical syntax
•  Textual syntax

23
Example
•  A model transformation in QVT Operational
– UML class to relational database schema

24
What comes next ?
•  Model Transformation Examples
– Model Synthesis
– Model Translation
– Model Simulation
– Model Analysis and Verification
– Generating Domain-Specific Modeling Languages
– Model Quality Improvement
– Model Co-Evolution

26
Model transformation examples
Model Synthesis
•  Extracting models from code
– Crucial activity in reverse engineering and program
comprehension
– Try to build a mental model from the code
– Is a vertical, exogenous
transformation
Source code
(e.g. Java)
Design model
(e.g. UML)

27
Model Synthesis
•  Example:
– Package diagram generated from Java code with
MagicDraw

28
Model Synthesis
•  Example:
– Class diagram
generated from Java
code with MagicDraw
(result after cleaning)

30
Model Translation
•  Model translation is a horizontal, exogenous
model transformation
– Can be used for different purposes
•  Translating UML models to formal models
– in order to achieve some form of formal analysis
•  UML2Alloy
•  UML activity diagrams to Petri nets
•  UML state diagrams to state machines
•  …
•  Translating between different “equivalent”
representations
•  UML to XMI
•  (E)MOF to Ecore
•  Class diagrams to Entity-Relationship diagrams

31
Model Translation
Example: UML to ER-diagrams.
– “Towards model transformation generation by example”.
Wimmer, Strommer, Kargl, Kramler, Proc. HICSS 2007
Concrete
Syntax

32
Model Translation
Example: UML to ER-diagrams

33
Model Translation
•  Exemple: UML to ER diagrams
– Implementation in ATL
– Rule for translating UML property into ER attribute

34
Model Translation
•  Exemple: ER to UML diagrams
– Implementation in ATL
– Backward rule to transform ER attribute into UML
property

36
Model Simulation
•  Petri Nets
– A type of model that formalises system state changes
by means of places that contain tokens that can
move to other places by means of transitions
triggered by events.
– Can be used for model verification purposes, e.g. to
give a precise semantics to UML activity diagrams
•  Formal properties of the Petri net (e.g. deadlock, livelocks,
reachability) can help to verify the quality of the
corresponding activity diagram

37
Model Simulation
•  Petri net notation
transition
empty place
place with tokens
Input
places
Output
places

38
Model Simulation
•  Petri net example
t3
t2
t1

39
Model Simulation
•  How to simulate the Petri net execution?
– Express Petri net as a model conform to a
metamodel
– Use model transformations to specify its operational
semantics
– Is a horizontal, endogenous model transformation
– We illustrate this by means of graph transformation
tool AGG

40
Model Simulation
•  Representing a Petri net as a graph …

41
Model Simulation
•  … that conforms to a type graph

42
Model Simulation
•  Petri net execution
– Firing transition t1
t3
t2
t1

43
Model Simulation
t3
t2
t1

44
Model Simulation
t3
t2
t1

45
Model Simulation
t3
t2
t1

46
Model Simulation
t3
t2
t1

47
Model Simulation
•  Simulating the Petri net by executing a graph
grammar that represents the operational
semantics
– Result after execution:

48
Model Simulation
•  Operational semantics is expressed as a graph
grammar, i.e., a set of graph transformation rules
NAC LHS RHS

49
Model Simulation
•  Operational semantics is expressed as a graph
grammar, i.e., a set of graph transformation rules

50
Model Simulation
•  Petri net concurrency:
– Two transitions can fire at the same time, provided
that they are not in conflict
–  The input places involved in both transitions should
be disjoint
– The graph grammar formalism naturally lends itself to
such concurrent behaviour

51
Model Simulation
•  Petri nets:
– Concurrency between t1 and t2
t3
t2
t1

52
Model Simulation
•  Petri nets
– Concurrency between t1 and t2
t3
t2
t1

54
Model Verification
•  Robert France: There is a need for formal
methods in the MDE context
– To perform model checking, model analysis and
model verification
– To verify properties of (sets of) model transformations
•  E.g. does a transformation preserve syntax, correctness,
semantics, consistency ?

55
Model Verification
•  Petri net revisited
•  Static verification of models
– Is the model syntactically correct ?
•  i.e. conform to type graph (read: metamodel) and additional
graph constraints
•  Static verification of model transformations
– Is the operational semantics of Petri net execution
syntactically correct?
•  i.e. each transformation rule produces a syntactically correct
target model

56
Model Verification
•  Dynamic verification
– Reachability analysis
•  Are all places in the Petri net reachable?
– Concurrency analysis
•  Is it possible to arrive in a “deadlock” or “livelock” situation?
– Termination analysis
•  Will the Petri net execution ever terminate?
– Confluence analysis
•  Do different execution traces lead to the same unique result
(for the same source model)

57
Model Verification
•  Dynamic verification
–  Is the source model realistic?
•  Is there at least one applicable rule?
–  Are all rules useful?
•  Can we find, for each rule, a scenario in which it is used?
–  Are all rules useful for the considered source model?
–  Are some rules mutually exclusive or sequentially
dependent?
•  We can use critical pair analysis to detect such situations

58
Model Transformation Analysis
Are some rules sequentially
dependent?
– use critical pair analysis to detect
such situations

59
Sequential dependency analysis
Informal definition
T2 sequentially depends on T1 if
•  T1 can be applied to G but T2 cannot
•  applying T1 triggers application of T2
G H1 X
T1 T2
Model Transformation Analysis
G H2
T2

61
Generating visual languages
•  Difference between abstract and concrete
syntax
metamodel
M2 level
M1 level
modeldiagram
visualises
conformsto
Visual language and
lay-out constraintsrespects
concrete syntax abstract syntax

62
•  Difference between abstract and concrete
syntax
:Place
token=1
name="p1"
:Place
token=2
name="p3"
:Place
token=0
name="p2"
:Transition
token=0
name="t"
:ArcPT
inscr="a1"
:ArcPT
inscr="a3"
:ArcTP
inscr="a2"
endArcPT
endArcPT
beginArcPT
beginArcPT
beginArcTP
endArcTP
• The number of tokens is shown inside the circle
• The place name is shown under the circle
• The transition name is shown inside the rectangle
• …
M2 level
M1 level
concrete syntax abstract syntax

63
•  Tiger Project tool setup
Tiger Eclipse plug-in
Metamodel specification
Visual syntax specification
Specification of
manipulation rules
Generated Eclipse plug-in
A domain-specific
modeling environment
AGG graph
transformation engine
uses
K. Ehrig, C. Ermel, S. Hansgen, G. Taentzer.
Generation of Visual Editors as Eclipse Plug-Ins.
Proc. Int’l Conf. Automated Software Engineering (ASE)
http://tfs.cs.tu-berlin.de/tigerprj/

64
•  Example: Petri nets
– What the end-user sees :
•  A tool for creating, manipulating, transforming Petri nets
•  Using concrete visual syntax

65
– What the developer sees :
•  A tool for specifying the metamodel / type graph
•  A tool for specifying the visual notation

66
– What the developer sees :
•  A tool for specifying instance models / graphs
•  Using the visual syntax notation

67
– What the developer sees
•  A tool for specifying model transformation through graph
transformation
•  Using visual notation

69
Model Transformation Examples
Model co-evolution
•  Modeling languages can evolve, too!
– Requires support for metamodel evolution
and language evolution
– To avoid language erosion and inconsistencies,
•  Models expressed in these languages need to
co-evolve (co-adapt)
•  Tools supporting these languages need to co-evolve too
model
“the real world”
Model
Modeling
language
conforms to
Evolved
language
Co-evolved
Model
conforms to

71
Model Quality Improvement
•  Model refactoring
– An endogenous horizontal model transformation that
improves the model’s structure while preserving its
behaviour and other quality aspects
•  What to preserve may depend on the context and type of
model
•  Model refactoring is based on the idea of
program (source code) refactoring
– "the process of changing a program in such a way
that it does not alter the external behavior of the
code, yet improves its internal structure" [Martin
Fowler, 1999]

72
Model Refactoring
•  One of the best known
references on program
refactoring, with
illustrative examples in
Java
– see also
www.refactoring.com

73
Model Refactoring
•  Model refactorings can be applied to any type of
UML model
– Class diagrams
– State-machine diagrams
– Sequence diagrams
– Activity diagrams
– …
Note: A model refactoring actually changes the model structure.
Sometimes, even simply changing the layout of a diagram that
visually represents a model can also help to improve
understandability.

74
Model Refactoring
for class diagrams
•  Pull Up Operation
Rectangle
rotate
Polygon
Triangle
rotate
UI
draw
Rectangle
Polygon
rotate
Triangle
UI
draw

75
Model Refactoring
for class diagrams
•  Push Down Operation
Rectangle
rotate
Polygon
Triangle
rotate
UI
draw
Rectangle
Polygon
rotate
Triangle
UI
draw

76
Model Refactoring
for class diagrams
•  Pull Up Association
Dog
Mammal
Horse
Eye
2 2
Tail
1 1
Dog
Mammal
Horse
Eye2
Tail
1

77
Model Refactoring
for class diagrams
•  Split Class
– Separate a class in 2 parts, and distribute its
attributes, operations and relations over these parts
A
a
b
d
m()
n()
A1
a
b
m()
B A2
d
n()
B
b
b

78
Model Refactoring
for class diagrams
•  Split Class (version 2)
– Separate a class into 2 parts related via
generalisation
A
a
c
d
m()
n()
A1
a
c
m()
B
A2
d
n()
B
b
b

79
Additional OCL constraint:
context Borrow inv:
let e: Borrow in
self.Book_copy = e.Book_copy and
self.Date = e.Date and self.Person = e.Person
implies self = e
Model Refactoring
for class diagrams
•  Turn ternary association into binary associations
Book copy Date
*0..1
Person
*
Borrow
Book copy Date
*0..1
Person
*
Borrow
11
1
Attention !
Inversed cardinalities

80
•  Turn association class into ordinary class
Model Refactoring
for class diagrams
Person Company
1..* 0..*
worksFor
Work Contract
annual revenue
Person Company
0..* 1..*
Work Contract
annual revenue
11

81
Model Refactoring
for state machine diagrams
•  Merge states

82
Model Refactoring
•  Split state
– Before the refactoring
Example from J.-M. Bruel, Université de Pau, France

83
Model Refactoring
•  Split state
– New behaviour we would like to insert into existing
state machine
(split NonEmpty state in two separate states)

84
Model Refactoring
•  Split state
– After the refactoring

85
Model Refactoring
•  Flatten states: Unfold incoming transitions
– Transition from state s1 to the boundary of a
complex state represents a transition from s1 to the
initial state of the complex state
a b
a
b

86
Model Refactoring
•  Flatten states: Unfold outgoing transitions
– Transition from boundary of complex state to state s1
represents corresponding transitions from all
substates to s1
a b
a
b
a

87
Model Refactoring
•  Example of “Flatten states”
– telephone communication: Unfold transitions between
Idle state and Active composite state

88
Model Refactoring
•  Example of “Flatten states”
– telephone communication: Remove the Active
composite state
Purpose of the transformation? End result is a finite state machine
that can be formally analysed by dedicated tools

89
Model Refactoring
•  Introduce/remove pseudostates
(fold transitions to composite state)
Forward
Second
Neutral
First
GearBox
Forward
Second
Neutral
First
GearBox

90
Model Refactoring
•  Replace transition activity by entry/exit activity
Opening
Closing
Closed
GarageDoor
Open
depress /
motor up
touch /
motor off
depress /
motor down
touch /
motor off
Opening
entry/motor up
Closing
entry/motor down
Closed
entry/motor off
GarageDoor
Open
entry/motor off
depress
touch
depress
touch

91
Model Refactoring
for activity diagrams
•  Make activities concurrent
– Create a fork and a join pseudostate, and move
several sequential groups of actions between them,
thus enabling their concurrent execution
! Can only be done if the activities are truly concurrent,
i.e., if they do not depend on one another
•  Sequentialize concurrent activities
– Removes a pair of fork and join pseudostates, and
links the enclosed group of actions to another
! Can only be done if the activities are truly concurrent,
i.e., if they do not depend on one another

92
Model Refactoring
•  Make (independent) activities concurrent

93
Model Refactoring
•  Sequentialize concurrent activities

95
Model Refactoring Support
using Graph Transformation
•  How to formally specify model refactorings?
•  Use graph transformations
– Each model refactoring is specified as a set of graph
transformation rules that need to be applied in a
certain order
– A graph transformation rule is composed of
•  LHS: left-hand side, i.e. the situation before applying the
refactoring
•  RHS: right-hand side, i.e. the situation after applying the
refactoring
•  NAC: one or more negative application conditions, restricting
the applicability of the rule

96
•  Tool support for graph transformation
– Many graph transformation tools exist
•  AGG, Fujaba, VIATRA2, GrGen, GReAT, VMTS, MOTMOT,
…
– Eclipse EMF support for model refactoring
(developed by German researchers)
•  Tiger Eclipse plug-in
http://tfs.cs.tu-berlin.de/emftrans/
– Supports model transformation for EMF, is based on
AGG
– Allows formal reasoning over transformation rules
– Uniform way to specify transformation of different
diagram types
•  Refactoring plug-in
– Supports model refactoring, is based on Tiger plug-in

97
•  Tiger EMF transformation project
– “flatten states” refactoring : first GT rule

98
•  Tiger EMF transformation project
– “flatten states” refactoring : second GT rule

99
•  Class diagram refactoring : Pull Up Attribute
– Step 1: Annotate all subclasses containing the
attribute to be pulled up

100
– Step 2: Pull up the attribute from all annotated
subclasses

101
– Step 3: After pulling up, delete the attribute in all
subclasses.

102
– Step 4: If there are still annotations, delete them.

103
•  Eclipse model refactoring plug-in
– Based on Tiger EMF transformation plugin
A class diagram
and its tree
view

104
•  Eclipse model
refactoring plug-in
– Selecting a model
refactoring …

105
•  Eclipse model
refactoring plug-in
– … and studying its
effect

106
•  Eclipse model refactoring plug-in
Result of
applying the
model
refactoring

107
•  Transformation dependency analysis
– Example of sequential dependencies between
refactorings

108
Graph Transformation Dependency Analysis
•  Sequential dependency analysis
– Example: PullUpVariable depends on
CreateSuperclass

109
Graph Transformation Dependency Analysis
•  Sequential dependency analysis
– Example: PullUpVariable depends on
CreateSuperclass
A
B
b
C
A
B
b
A
B
b
C∂ ∂
CreateSuperclass PullUpVariable

110
Conclusion
There is still a long way to go…

Model Transformation: A survey of the state of the art

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Model Transformation: A survey of the state of the art

Ähnlich wie Model Transformation: A survey of the state of the art (20)

Mehr von Tom Mens

Mehr von Tom Mens (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Model Transformation: A survey of the state of the art