Model Transformation Eugene SyrianiandHans Vangheluwe.

Model Transformation

Eugene Syriani and Hans Vangheluwe

2

Model TransformationOutline

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

3

Model Transformation1 What is 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)]

4

Model TransformationIn a model-driven engineering (MDE) framework

• Everything is modelledTherefore a change will always be on a model.

• We explicitly model everythingA change or modification must itself be modelled models of transformations.

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

M M’

MM MM’MM

confo

rms

to

confo

rms

to

confo

rms

to

5

Model TransformationTerminology

Model-to-model transformation

• Multiple sources

• Multiple targets

• The transformation can be interpreted or the result of compilation

TargetMeta-model

Transformation

Transformation

Definition

Target

Model

Source

Model

SourceMeta-model

reads outputs

refers to refers to

confo

rms

to

exe

cute

s

confo

rms

to

6

Model TransformationUses & Needs In Language Engineering

The meta-model of a language L defines:1. The abstract syntax of L2. 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.

7



• 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

8



• 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

Statecharts model Generated Python code

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

s1 s2

e

9


• 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

10


• 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

11


• 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

12

Model TransformationTypes of transformations

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)

13


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

14


• 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

15


• 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

16


• 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

17


• Common Uses of Model Transformation

• Reverse Engineering

Inverse of synthesis: extract higher-level specifications from lower-level ones

• C# to UML Class Diagram

18



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

PhoneApps DSM of the same modelStatechart representing a conference registration model

19



• Simulation

• Update the state of the model

• Operational semantics

20



• 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 3.0Enterprise Java Beans 2.0

21



• Optimization

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models

SSheet

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

Dictionary

Mapping

SSheetCell

- coordinate: Coordinate

+ getValue() : CellValue+ setValue(CellValue) : void

«struct»Coordinate

- row: int- column: int

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

1

+cells

1 *

+key 1 +value *

SSheet

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

2DArray 2DItem

- index: int

SSheetCell

- coordinate: Coordinate

+ getValue() : CellValue+ setValue(CellValue) : void

«struct»Coordinate

- row: int- column: int

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

ArrayItem

- index: int

+items

*1

+cells

1

+value 1

+items

*

+value

1

List to table optimization

22



• 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

23



• 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

• Map the concrete syntax back to the abstract syntax

H H

H

H

C

H

H

C OCH3 CH2 OH

24



• Composition

Integrate models that have been produced in isolation into a compound model

Model merging

Model weaving

25



• 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

26

Model TransformationClassification of the types of transformations

• 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

27


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

Endogenous Exogenous Either

Horizontal

Access/Modify, Simulation, API migration Language migration Compositio

n

Vertical

Formal refinement, Restructuring,

Restrictive query, Optimization, Simplification

Aggregate query, Synthesis, Reverse

engineering, Desugaring

X

28



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

29



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

DSM in CS ASG

Code

parse

refactor/optimize

synthesize

ASG’ synth

esiz

e

migrate

Model transformation chain to compile a DSM into executable Java code

Syntactical Query Synthesis

ReverseEngineerin

g

Simplification Desugaring - -

Semantical

Access /

Modify

Simulation Migration Optimizatio

nRestructurin

gCompositio

nSynchronizati

on

30

Model Transformation2 Family of Transformation Languages

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.

31

Model TransformationFamily of Transformation Languages

• 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-featureat a later stage

32


• Feature diagram

• Example:

33


• Features of model transformation languages [Czarnecki06]

• SpecificationPre/post condition on the transformation:

• Function between source & target models• Relation may be executable or not

• Transformation RulesSmallest transformation unit, used to specify a transformation

• Rule-based transformations: pre-condition & post-condition for rewriting

• Transformation units defined as functions• Templates

• Rule OrganizationGeneral structuring issues of

rules• Modularization• Composition• Re-use

• Source-Target Relationship

• In-place• Out-place

• IncrementalityAbility to update existing target models based on

changes in the source models

• DirectionalityTransformation executed in one direction or in multiple

directions (uni-/multi-directional transformation)

• TracingMechanisms for recording different aspects of

transformation execution:• Create & maintain trace links between source & target model

elements

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

34


• Transformation Rules

• Smallest transformation units

• A model transformation is mainly specified in terms of rules

:

:

35


• 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

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

}

QVT-Relations rule [OMG08]

36


• Domain Body

• Patterns

Model fragment internally represented as:

• Strings: Template-based transformation

• Terms: tree representation of models

• Graph: Model-to-model transformation

37


• 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

38


• Domain Body

• Logic

Declarative vs. Imperative

Kermeta operation [Falleri06]

operation transform(source:PackageHierarchy): DataBase is doresult := DataBase.newtrace.initStep(“uml2db”)source.hierarchy.each{ pkg |

var scm: Schema init Schema.newscm.name := String.clone(pkg.name)result.schema.add(scm)trace.addlink(“uml2db”, “package2schema", pkg, scm)

}end

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

}

QVT-Relations rule

39


• Domain of Rule

• Typing

of variables, patterns, and logic

• Untyped: free text / free hand drawing

• Syntactical typing: variable is associated witha 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 rulewill satisfy certain properties, if the input modelsatisfies some properties.

FUJABA [Fischer00] transformation pattern

40


• Syntactic Separation

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

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

rule Start {form p: MMa!Person(

p.function = ‘Boss’)to c: MMb!Contact(

name <- p.first_name + p.last_name)}

MoTif [Syriani09a] rule

ATL rule

FUJABA: compact notation

41


• Multi-directionality

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

top relation PackageToSchema {domain uml p:Package {name = n}domain rdbms s:Schema {name = n}

}

QVT-Relations rule

TGG rule

42


• Application Conditions

Pre-condition for the rule before it is executed

• QVT-R: when clause

• AToM3: rule-level constraint [Lara02]

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

}

43


• 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

44


• 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

45


• 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

46


• Location Determination

Strategy for determining the application locations of a rule

Model:

Rule:

47


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

Model:Rules:,

48


• Rule Scheduling

• Form

• Explicit internal: a rule may invoke other rules.

• In ATL [Jouault08], a matched rule (implicitly scheduled) may invoke a called rule in its imperative part. Lazy rules

• In QVT, the when/where clauses of a rule may have a reference to other rules.When: the former will be applied after the latter. Where: the latter will be applied after the former.

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

}

49


• 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

50


• Rule Scheduling

Priority-based: AToM3

51


• Rule Scheduling

Layered/Phased: AGG

52


• Rule Scheduling

Explicit workflow

GReAT data flow

FUJABA story diagram

53


• Explicit Scheduling features [Syriani09]

PRoGReS FUJABA VIATRA AToM3 GReAT VMTS[Lengyel06]

MoTif

Control structure

Imperative language

Story Diagram

Abstract state

machine

Priority ordering

Data flowActivity diagram

DEVS

Atomicitytransaction,

ruleRule gtrule Rule Expression Step ARule

Sequencing

& Yes seq Implicit Yes Yes Yes

Branchingchoose...els

eBranch activity

if-then-else No Test / CaseDecision step, OCL

Query

Looping loopFor-all

patterniterate, forall

Implicit Yes Self loopFRule,

SRule, LRule

Non-determinis

mand, or No random Within layer

1−n connection

NoSelector pattern

Recursion Yes No Yes No Yes Yes Yes

Parallelism No Optional No Optional No Fork, JoinSynchronize

r pattern

Back-tracking

Implicit Nochoose

(implicit)No No No XRule

HierarchyModularisati

onNested state Yes No

Block, ForBlock

High-level step

CRule

54


• 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

55


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

56


• 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

57


• Incrementality

• An incremental transformation is defined as a set of relations between a source and target meta-models. 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

58


• 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

59


• TGG rules are bi-directional

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

TGG operational rules

60


• Tracingis the runtime footprint of a transformation execution

• Traceability links connect source & target elementsThey 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

61

Model TransformationDifferent Model Transformation Approaches

• 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

62

Model Transformation3 Rule-based Transformation

• By Example:

Simplified PacMan formalism [Heckel06]

63

Model TransformationRule-based Transformation

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

64


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

65



14

2

1

2

5 pacLink

3

ghostLink

3

ghostLink

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

1

2

3

1

2

35

4

pacLink

foodLink

6

4

pacLink

P 1

P 2

66



4

1 2

35

gridLeft

ghostLink

1 2

3

4

6

gridLeft

ghostLink

4

1 2

6

gridRight

pacLink

1 2

4

5

gridRight

pacLink

33

P 3

P 3

67


• Simulation of a model

1. pacmanDie

2. pacmanEat

3. ghostMoveLeft

4. ghostMoveRight

5. ghostMoveUp

6. ghostMoveDown

7. pacmanMoveLeft

8. pacmanMoveRight

9. pacmanMoveUp

10. pacmanMoveDown

P1

P2

P3

68


• Mechanics of Rule Application

right

right

left

right

left

up down up down

right

L K R

G

gLink gLink

gLink

pLink fLink

right

left

right

left

up down up down

G’

gLink

pLink fLink

m

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

69


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: m(L).

• Thus, 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) from G.

2. Create the new elements of R-K in G.

3. Update the properties of the elements in 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.

70


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

71


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

72

Model TransformationMost Used Rule-based Transformation Tools

• Programmed Graph Rewriting System: ProGReS

Manfred Nagl Andy Schürr Albert Zündorf

1988-1999

University of Aachen (Germany)


• Programmed Graph Rewriting System: ProGReS

73

74


• From UML to JAVA And Back Again: FUJABA

Since 1998

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

75


• From UML to JAVA And Back Again: FUJABA

76


• MOFLON

Since 2004

University of Darmstadt (Germany)

77


• MOFLON

78


• Graph Rewriting and Transformation: GReAT

Gabor Karsai Aditya Agrawal

Since 2001

Vanderbilt University, Nashville (USA)

79


• Graph Rewriting and Transformation: GReAT

80


• Visual Modelling and Transformation System: VMTS

Since 2004

Budapest University of Technology and Economics (Hungary)

Tihamér Levendovszky László Lengyel

81


• Visual Modelling and Transformation System: VMTS

82


• Graph Rewriting and Transformation: VIATRA

Since 2002, VIATRA2 since 2006

Budapest University of Technology and Economics (Hungary)

Dániel Varró

83


• Graph Rewriting and Transformation: VIATRA

84


• ATLAS Transformation Language: ATL

Since 2005

École des Mines de Nantes (France)

Jean Bézivin Frédéric Jouault

85


• ATLAS Transformation Language: ATL

86

Model TransformationPrimitive Transformation Operations

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

87


T-Core Module [Syriani10]

• Pattern representation

• Matches processed structure

• 8 primitive transformation operators

88


T-Core Module

Dissociate pre- from post-condition patterns

‒ Query vs. Rule

‒ Embedded inside Matcher & Rewriter

89


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

90


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

91


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

92


T-Core Module

• Selector

‒ Can store packets

‒ Select one on demand

• Synchronizer

‒ Can store packets

‒ Merge packets on demand

‒ Customizable merge function

93


T-Core Module

• Meaningfully compose its sub-primitives

• User-defined composition

• Common interface

94


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

95


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

96


97


Query

98


Atomic Rule

99


Rule applied as long as possible

100


Combining rules with Python

101

Model Transformation4 What is Required for Industrial Adoption?

• 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

102

Model TransformationWhat is Required for Industrial Adoption?

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

103

Model TransformationWhat is Required for Industrial Adoption?

• 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

104

Model TransformationMaking a Well-Informed Choice

• 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

105

Model TransformationReferences

[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 Domain-Specific 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.

106


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

107


[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, Elsevier2006.

108

Model TransformationAdditional References

• 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

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

Model Transformation Eugene SyrianiandHans Vangheluwe.

Documents

Transcript of Model Transformation Eugene SyrianiandHans Vangheluwe.