model transformation: a survey of the state of the art

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

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.”

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

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

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

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

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

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

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

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 – …

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

7

Model Transformation Support

•  In order to provide automated support for model transformation, we need

– Formal methods – Standards – Methodologies / Processes – Tools – Transformation languages

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

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)

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

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 – …

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

10


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

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

11

Model Transformation 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

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

13


•  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)

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

14


•  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

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

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

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

16


• 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

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

17


Text-based languages •  ATL •  Kermeta •  Tefkat •  SiTra •  QVT Operational •  QVT Relational

Visual languages •  GReAT •  VIATRA2 •  AGG •  ATOM3 •  Fujaba •  MOFLON •  QVT Relational

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

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 ) }

Model Transformation Languages Example

• A model transformation in ATL – Replace inheritance by aggregation in a class

diagram, part 1 textual and procedural

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

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 ) }


• A model transformation in ATL – Replace inheritance by aggregation in a class

diagram, part 2 textual and procedural

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

20


• A model transformation in Fujaba – Pull up method in a class diagram

visual and declarative

based on control flow

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

21


• A model transformation in GReAT – Generation of Sierpinski triangles visual and

declarative

based on data flow

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

22


• A model transformation in QVT Relational – UML class to relational database schema

• Graphical syntax

•  Textual syntax

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

23


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

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

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

Model transformation examples

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

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)

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

27


• Example: – Package diagram generated from Java code with

MagicDraw

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

28


• Example: – Class diagram

generated from Java code with MagicDraw (result after cleaning)

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

30

Model transformation examples 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

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

31


Example: UML to ER-diagrams. – “Towards model transformation generation by example”.

Wimmer, Strommer, Kargl, Kramler, Proc. HICSS 2007

Concrete Syntax

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

32


Example: UML to ER-diagrams

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

33


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

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

34


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

property

Model Transformation examples

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

36

Model transformation examples 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

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

37


• Petri net notation

transition

empty place

place with tokens

Input places

Output places

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

38


• Petri net example

t3

t2

t1

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

39


• 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

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

40


• Representing a Petri net as a graph …

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

41


• … that conforms to a type graph

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

42


• Petri net execution – Firing transition t1

t3

t2

t1

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

43



t3

t2

t1

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

44



t3

t2

t1

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

45



t3

t2

t1

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

46



t3

t2

t1

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

47


• Simulating the Petri net by executing a graph grammar that represents the operational semantics

– Result after execution:

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

48


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

NAC LHS RHS

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

49


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

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

50


• 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

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

51


• Petri nets: – Concurrency between t1 and t2

t3

t2

t1

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

52


• Petri nets – Concurrency between t1 and t2

t3

t2

t1

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

54

Model transformation examples 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 ?

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

55


• 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

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

56


• Petri net revisited • 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)

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

57


• Petri net revisited • 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

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

58

Model transformation examples Model Transformation Analysis

Are some rules sequentially dependent?

– use critical pair analysis to detect such situations

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

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 examples Model Transformation Analysis

G H2 T2

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

61

Model transformation examples Generating visual languages

• Difference between abstract and concrete syntax

metamodel

M2 level

M1 level

model diagram visualises

conf

orm

s to

Visual language and

lay-out constraints re

spec

ts

concrete syntax abstract syntax

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

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

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

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/

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

64


• Example: Petri nets – What the end-user sees :

•  A tool for creating, manipulating, transforming Petri nets • Using concrete visual syntax

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

65


• Example: Petri nets – What the developer sees :

•  A tool for specifying the metamodel / type graph •  A tool for specifying the visual notation

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

66


• Example: Petri nets – What the developer sees :

•  A tool for specifying instance models / graphs • Using the visual syntax notation

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

67


• Example: Petri nets – What the developer sees

•  A tool for specifying model transformation through graph transformation

• Using visual notation

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

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

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

71

Model transformation examples 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]

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

72

Model transformation examples Model Refactoring

•  One of the best known references on program refactoring, with illustrative examples in Java

– see also www.refactoring.com

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

73

Model transformation examples 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.

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

74

Model Refactoring for class diagrams

• Pull Up Operation

Rectangle rotate

Polygon

Triangle rotate

UI draw

Rectangle

Polygon rotate

Triangle

UI draw

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

75


• Push Down Operation

Rectangle rotate

Polygon

Triangle rotate

UI draw

Rectangle

Polygon rotate

Triangle

UI draw

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

76


• Pull Up Association

Dog

Mammal

Horse

Eye 2 2

Tail 1 1

Dog

Mammal

Horse

Eye 2

Tail 1

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

77


• 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

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

78


• 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

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

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


•  Turn ternary association into binary associations

Book copy Date * 0..1

Person

*

Borrow

Book copy Date * 0..1

Person

*

Borrow 1 1

1

Attention !

Inversed cardinalities

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

80

•  Turn association class into ordinary class


Person Company 1..* 0..*

worksFor

Work Contract annual revenue

Person Company 0..* 1..*

Work Contract annual revenue

1 1

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

81

Model Refactoring for state machine diagrams

• Merge states

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

82


• Split state – Before the refactoring

Example from J.-M. Bruel, Université de Pau, France

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

83


• Split state – New behaviour we would like to insert into existing

state machine (split NonEmpty state in two separate states)

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

84


• Split state – After the refactoring

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

85


•  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

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

86


•  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

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

87


• Example of “Flatten states” – telephone communication: Unfold transitions between

Idle state and Active composite state

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

88


• 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

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

89


•  Introduce/remove pseudostates (fold transitions to composite state)

Forward

Second

Neutral

First

GearBox

Forward

Second

Neutral

First

GearBox

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

90


• 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

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

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

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

92


• Make (independent) activities concurrent

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

93


• Sequentialize concurrent activities

Model Refactoring Support

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

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

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

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

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

97


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

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

98


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

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

99


• Class diagram refactoring : Pull Up Attribute – Step 1: Annotate all subclasses containing the

attribute to be pulled up

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

100


• Class diagram refactoring : Pull Up Attribute – Step 2: Pull up the attribute from all annotated

subclasses

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

101


• Class diagram refactoring : Pull Up Attribute – Step 3: After pulling up, delete the attribute in all

subclasses.

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

102


• Class diagram refactoring : Pull Up Attribute – Step 4: If there are still annotations, delete them.

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

103


• Eclipse model refactoring plug-in – Based on Tiger EMF transformation plugin

A class diagram and its tree view

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

104


• Eclipse model refactoring plug-in

– Selecting a model refactoring …

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

105



– … and studying its effect

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

106



Result of applying the model refactoring

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

107


•  Transformation dependency analysis – Example of sequential dependencies between

refactorings

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

108

Model Refactoring Support Graph Transformation Dependency Analysis

• Sequential dependency analysis – Example: PullUpVariable depends on

CreateSuperclass

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

109

Model Refactoring Support 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

© T

om M

ens,

Um

ons,

200

9 In

tern

atio

nal S

choo

l MD

D4D

RE

S, A

usso

is

110

Conclusion

There is still a long way to go…

model transformation: a survey of the state of the art

Education