Model transformations in the VIATRA2 framework

Budapest University of Technology and Economics

Model Transformations in the
VIATRA2 Framework

István Ráth Dániel Varró
PhD candidate Associate professor

Dept. of Measurement and Information Systems

Fault-tolerant Systems Research Group
1


Overview - Outline
 Introduction
− Motivation for model transformations
− Main concepts of MTs
 The VIATRA2 transformation language
− Models and Metamodels
− Graph Patterns and Graph transformation
− Controlled transformations (Abstract state machines)
 Advanced Transformation concepts
− Synchronization with Event-driven Transformations
− Constraint satisfaction problems over models
− Model simulation
 Applications in practice: Model-driven tool integration
− SENSORIA
− Embedded domain

2


Challenges for Software Development

3


 A typical design process of a large system involves
− Many stakeholders
− Many development teams
− Many manmonths
− MANY TOOLS
● Requirements, Analysis, Design, Testing, Maintenance, …

3


− Many manmonths
− MANY TOOLS
 Tool integration is a major challenge
− Design of Embedded / Critical systems:
Cost of tool integration ≈ Cost of the tools themselves

3


− Many manmonths
− MANY TOOLS
 Tool integration is a major challenge
− Design of Embedded / Critical systems:
Cost of tool integration ≈ Cost of the tools themselves
 Why?
− Continuous evolution / changes of tools
− Each having its own (modeling / programming) language
− Difficult to build correct and robust bridges between them

3


Model Transformation for Tool Integration
System design

High-level
System
Model
(UML, BPM,
DSL)

4


System design
Model
generation

High-level
System
Model
(UML, BPM,
DSL)

4


System design
Model
generation

High-level
System
Model
(UML, BPM,
DSL) List of
inconsistencies

4


System design
Model
generation

High-level
System Refinement
Model
(UML, BPM,
DSL) List of
inconsistencies

4


System design Mathematical analysis
Model
generation Mathematical
High-level
Refinement
model
System
Model
(UML, BPM,
DSL) List of
inconsistencies
Analysis

4


System design VIATRA2 Mathematical analysis
Model
High-level
Refinement
model
System
Model
(UML, BPM,
DSL) List of
inconsistencies
Analysis

4


Model
High-level
Refinement
model
System
Model
(UML, BPM,
DSL) List of
inconsistencies
Analysis
Code gen

Implementation

4


Model
High-level
Refinement
model
System
Model
(UML, BPM,
DSL) List of
inconsistencies
Analysis
Auto-
Deployment Code gen

Implementation
Deployment desc
Dependable
platform

4


Model
High-level
Refinement
model
System
Model
(UML, BPM,
DSL) List of
inconsistencies
Analysis
Auto- Monitor
Deployment Code gen
generation
Implementation Runtime
Deployment desc monitoring
Dependable IT Monitoring
platform System

4


THE MODEL
TRANSFORMATION PROBLEM

5


Native (Ad Hoc) Model Transformations

Native Manually written Native
Source model native program Target model

Vendor’s own tool
6



Native source models:
• EMF
• XML documents
• Databases
• Domain-specific models
• UML


Vendor’s own tool
6



Native source models: Native target models:
• EMF • EMF
• XML documents • App source code
• Databases • XML deployment descript.
• Domain-specific models • Databases
• UML • Analysis tools


Vendor’s own tool
6


Models, Metamodels, Transformations

VIATRA Model Space (VPM)
Source Xform. rules Target
metamodel (GT+ASM) metamodel

Source Target
model model

Native Native
Source model Target model

Vendor’s own tool
7




Source Target
model Model: Description of a model
concrete system
(see Eclipse EMF)

Native Native

Vendor’s own tool
7


Metamodel: Precise spec of
a modeling language
(see Eclipse EMF - Ecore)


Source Target
concrete system
(see Eclipse EMF)

Native Native

Vendor’s own tool
7


Metamodel: Precise spec of Transformation:
a modeling language How to generate
(see Eclipse EMF - Ecore) a target equivalent of
an arbitrary source model

Source Target
concrete system
(see Eclipse EMF)

Native Native

Vendor’s own tool
7


Transformation Engine

Eclipse framework
VIATRA2 Model Transformation Plug-in


Source Target
Xform engine
model model

Native Native

Vendor’s own tool
8


Transformation Engine

Eclipse framework


Source Target
Xform engine
model model

Transformation engine:
Support for querying and
Native manipulating large models Native

Vendor’s own tool
8


Standalone Transformation Plugins

Eclipse framework


Source Target
Xform engine
model model
Meta XForm

Native Native Native
Source model XForm Plugin Target model

Vendor’s own tool
9


Standalone Transformation Plugins

Eclipse framework


Source Target
Xform engine
model model
Standalone transformation:
Meta XForm
Independent of transformation
development environment

Source model XForm Plugin Target model

Vendor’s own tool
9


The VIATRA2 framework

Eclipse framework

VPM Metamodeling Core
PIM Xform. rules SCADE
metamodel (UML/QVT) metamodel

Source Xform engine Target
PIM model (ASM+GraTra) SCADE model
Transformation Design
Meta XForm

PIM model Transformation ExecutionSCADE model
XForm Plugin

Vendor’s own tool
10


Traceability of Transformations

VIATRA2 Model Transformation Service

Source Reference Target
metamodel metamodel metamodel

model model model

Native Native

Service Consumer
11


Traceability of Transformations



model model model

Traceability:
• Show the source element
Native for a target element Native
Source model • Show the target element Target model
for a source element
Service Consumer
11


Back-Annotation of Analysis Results



model model model

Native Native
Source model Result model

Modeling Tool Analysis Tool
12


The VIATRA2 Framework @ Eclipse

http://www.eclipse.org/gmt/VIATRA2
13


The VIATRA2 Approach
 Model management:
− Model space: Unified, global view of
models, metamodels and transformations
● Hierarchical graph model
● Complex type hierarchy
● Multilevel metamodeling
 Model manipulation and transformations:
integration of two mathematically precise,
rule and pattern-based formalisms
− Graph patterns (GP): structural conditions
− Graph transformation (GT): elementary xform steps
− Abstract state machines (ASM): complex xform programs
 Code generation:
− Special model transformations with
− Code templates and code formatters

14


Metamodeling in VIATRA2 (VTML)
entity(family) {
Entity relation(members, family, person);
Entity isAggregation(members, true);
Family
Relation }
familyName:String
entity(person) {
relation(parent,person,person);
relation(father,person,man);
father multiplicity(father, many_to_one);
members
* refines supertypeOf(parent,father);
parent relation(firstname, person,
Person datatypes.String);
firstname:String }
lastname:String mother entity(woman) {
parent
refines relation(husband, woman, man);
parent
multiplicity(husband, one_to_one);
}
husband
Man Woman supertypeOf(person,woman);
wife
entity(man) {
relation(wife, man, woman);

15


Metamodeling in VIATRA2 (VTML)
entity(family) {
relation(members, family, person);
Aggregation
Relation isAggregation(members, true);
Family
}
familyName:String
entity(person) {
Multiplicity
Relation relation(parent,person,person);
relation(father,person,man);
father multiplicity(father, many_to_one);
members
* refines supertypeOf(parent,father);
parent relation(firstname, person,
Person datatypes.String);
firstname:String }
lastname:String mother entity(woman) {
parent
refines relation(husband, woman, man);
parent
multiplicity(husband, one_to_one);
}
husband
Man Woman supertypeOf(person,woman);
wife
entity(man) {
Supertype relation(wife, man, woman);

16


Models in VIATRA2 (VTML)
namespace people.models;
mother Namespace,
man import people.metamodel;
father
Imports
woman wife/husband family('Varro1') {
man('Gyozo') {
Family Varro1
Instance man.wife(wf1, Gyozo, Maria);
definition }
Gyozo Maria woman('Maria') {
woman.husband(hb1, Maria, Gyozo);
}
Explicit
man('Daniel');
Daniel Gergely instance-of
entity('Gergely');
instanceOf(Gergely, man);
person.father(f1,'Gergely','Gyozo');
person.mother(m1,'Gergely','Maria');
family.members(mb1, 'Varro1', 'Gyozo');
Value family.members(mb2, 'Varro1', 'Maria');
OO datatype family.members(mb3, 'Varro1', 'Gergely');
family.members(mb4, 'Varro1', 'Daniel');

17


mother Graphical notation Containment View
father
Family Varro1
wife/
husband Gyozo Maria
man

woman
Daniel Gergely

m1:mother

Gyozo:Man Maria:Woman
f1:father
m1:mother
f1:father

Daniel:Man Gergely:Man

mb4:members mb3:members
mb1:members mb2:members
Varro1:Family
fn:familyname
str:String  "Varro"

Graph view
18


Comparison to EMF
EMF VPM / VIATRA

Namespace Only for Both models and
metamodels metamodels
Navigation As explicitly defined Always bidirectional

Generalization Only for classes Boths for classes
and references
Containment Along references Independent from
references
Generics Uni-directional Bi-directional
instance-of instance-of
19


− Special model transformations with
− Code templates and code formatters

20


Pattern definition Graphical notation
pattern brother(X,B)
Family Varro1 mother
P: Person father
P Gyozo Maria wife/
P1:person P2:person
husband
man
X: Person B: Man B
X Daniel Gergely woman

check (X != B)

matching
 Graph Pattern:
m1:mother
− Structural condition that have to be
fulfilled by a part of the model space
Gyozo:Man Maria:Woman
 Graph pattern matching:
f2:father
f1:father m2:mother − A model (i.e. part of the model space)
can satisfy a graph pattern,
− if the pattern can be matched to a
Daniel:Man Gergely:Man
subgraph of the model
Instance Model
21


Graph patterns (VTCL)
// B is a brother of X
pattern brother(X,B) pattern brother(X, B) =
{
P: Person person(X);
P1:person P2:person person.parent(P1, X, P);
person(P);
X: Person B: Man person.parent(P2, B, P);
man(B);
check (X != B)

22


Graph patterns (VTCL)
// B is a brother of X
pattern brother(X,B) pattern brother(X, B) =
{
P: Person person(X);
P1:person P2:person person.parent(P1, X, P);
person(P);
X: Person B: Man person.parent(P2, B, P);
man(B);
check (X != B)
// S is a sister of X
pattern sister(X,S, F) pattern sister(X, S, F) = {
F: Man person(X) in F;
person.father(P1, X, M);
P1:father P2:father man(M) in F;
OR pattern
X: Person S:Woman person.father(P2, S, M);
OR woman(S) in F;
} or {
M: Mother person(X) in F;
P1:mother P2:mother person.mother(P1, X, W);
woman(W) in F;
X: Person S:Woman
person.mother(P2, S, W);
22


Negative patterns (VTCL)
pattern mayMarry(M,W) pattern mayMarry(X, D) = {
man(M);
F1: Family F2: Family
family(F1);
MB1:members MB2:members family.members(MB1, F1, M);
woman(W);
M: Man W:Woman Negative family(F2);
pattern family.members(MB2, F2, W);
neg find married(M);
X X neg find married(W);
neg find neg find
married married check (F1 != F2);
}
check (F1 != F2)
pattern married(X) =
pattern married(X) {
man(X);
X: Man W: Woman
P1:person man.wife(WF, X, W);
OR woman(W);
M: Man X: Woman } or {
P1:person woman(X);

23


Recursive patterns (VTCL)

pattern descendants(X, D) = {
pattern descendants(X,D)
person(X);
X: Person person.parent(P2, Ch, X);
OR pattern
Recursive person(Ch);
P1:father
pattern find descendants(Ch, D)
Ch: Person D:Person
person(D);
} or {
X D person(X);
find descendants person.parent(P1, D, X);
OR person(D);
P1:parent

D: Person X: Person

24


Graph transformation rules (VTCL)
precondition pattern postcondition pattern
lhs(M,W,F1,MB1,F2,MB2) rhs(M,W,F1,MB1,F2,MB2,F)

F1: Family F2: Family F1: Family F2: Family
Precondition
MB1:members MB2:members pattern
M: Man W:Woman
M: Man W:Woman
MB1:members MB4:members

X X F: Family
neg find neg find
married married Postcondition
pattern
gtrule marry(in M, in W, out F) =
precondition pattern postcondition pattern
lhs(M,W,F1,MB1,F2,MB2) = { rhs(M,W,F1,MB1,F2,MB2) = {
family(F1); family(F1);
family.members(MB1, F1, M); man(M);
man(M); family(F2);
family(F2); woman(W);
family.members(MB2, F2, W); family(F);
woman(W); family.members(MB3, F, M);
neg find married(M); family.members(MB4, F, W);

25


Graph transformation rules (VTCL)
precondition pattern
lhs(M,W,F1,MB1,F2,MB2)

F1: Family F2: Family
Precondition
MB1:members MB2:members pattern

M: Man W:Woman

X X
neg find neg find
married married Action
Part
gtrule marry(in M, in W, out F) =
precondition pattern
action
lhs(M,W,F1,MB1,F2,MB2) = {
{
family(F1);
family.members(MB1, F1, M); delete(MB1);
man(M); delete(MB2);
family(F2); new(family(F));
family.members(MB2, F2, W); new(family.members(MB3, F, M));
woman(W);
new(family.members(MB4, F, W));
neg find married(M);

26


Structure of GT rules

NEG LHS RHS

X Z X X Y

 gtrule myRule(X,Y)
 Interface with ASM
− Input variables Input Output
− Output variables
− (in Prolog style) X Y
 All parameters can be typed

27


Generic GT rules (VTCL)
gtrule parentIsAncR(Par,Child)

precondition lhs(Par,Child) postcondition rhs(Par,Child)
P1:parent E:anc
Par:Class Child:Class Par:Class Child:Class
P1:parent

gtrule parentIsAncR(Par,Child,ClsE,ParR,AncR)

precondition lhs(Par, Child, P1 postcondition rhs(Par, Child, P1
ClsE,ParR,AncR) ClsE,ParR,AncR)

ParR: AncR: ParR: AncR:
relation ClsE:entity relation relation ClsE:entity relation

P1:relation P1:relation
Par:entity Child:entity Par:entity Child:entity
E:relation

28


Abstract State Machines
 ASM: high-level forall X below people.models,
B below people.models
specification language
with find brother(X, B) do seq {
− Control structure for xform
print(name(X) + "->" + name(B));
− Integrated with GT rules }
 Examples
− update location = term; let X = people.models.Varro1.Daniel,
− parallel {…} / seq {…} Y = people.models.Gyapay1.Szilvia,
− let var = term in rule; F = undef, F2 = undef in
− if (formula) rule1; else rule2; choose Z below people.models
− iterate rule; apply marry(X, Y, F) do seq {
− forall/choose variables rename(F, "Varro2");
with formula do rule; move(F, people.models);
− forall/choose variables iterate
apply gtrule do rule; choose M below people.models,
W below
GT extensions to ASMs people.models apply marry(M,
• Permanent states (models) + elementary model manipulation
29


Iterate choose vs. Forall
 Executes a GT rule as  Executes a GT rule for
long as possible each match one by one
 Potential nontermination  Potentially conflicting
effects

// This may cause nontermination if the same // This may cause a conflict when X and B
// match for X and B is enabled after the // are both man, and they are brothers
// body of seq is executed
iterate choose X, B with find brother(X, B) do forall X, B with find brother(X, B) do seq {
seq { delete(X);
}
}

30


− Special model transformations driven by graph patterns
− Code templates and/or print rules

31


Code templates (Ongoing)
 Code generation template printClass(in C) =
{
− Code templates public class $C {
− Code formatters #(forall At,Typ with attrib(C,At,Typ) do seq{)
 Code templates (alpha) private $Typ $At;
#(})
− Text block with references }
to GTASM patterns, rules }
− Compiled into GTASM
programs with prints // Result
≈ Velocity templates rule printClass(in C) = seq {
print("public class " + C + "{");
 Code formatters forall At,Typ with attrib(C,At,Typ) do
− Split output code into seq {
multiple files print("private " + Typ + " " + At + ";");
− Pretty printing }
print("}");

32


Other advanced MT issues
 Reusability
− Pattern composition (find)
− Rule calls (call)
 Traceability
− Reference metamodels
− Explicit storage of reference models
 Extensibility
− Native transformations:
written in Java, called from MT programs
− Integration of domain-specific models

33


ADVANCED
TRANSFORMATION
CONCEPTS
34


Incremental graph pattern matching
 … previous talk

35


What really is the incremental pattern matcher?
 Graph patterns ~ complex constraint sets
− Matching set: overlay of “valid” elements
 RETE: a complex overlay cache of the model
graph
− Stores matching sets explicitly
 A historical cache
− Can store “previous” overlay states

36


Idea
 Use the historical overlay to
− Easily compute non-trivial change information (beyond
elementary changes)
● Detect high-level “events”
● Detect (the net effect of) complex change sequences
− Assign actions to these changes
● Event-Condition-Action formalism in rule-based systems
●  event-driven transformations
− Or, easily track the validity set of constraints as the model is
evolving
●  constraint satisfaction solving
− Or, easily track enabledness conditions for simulation rules
●  stochastic model simulation

37


Event-‐driven
and
live
transforma1ons
 Core
idea:
represent
events
as
changes
in
the
matching

set
of
a
pa3ern.
− More
general
than
previous
approaches
− Use
events
and
reac:ons
as
transforma:on
speciﬁca:on
 Live
transforma:ons
− maintain
the
context
(variable
values,
global
variables,
…);
− run
as
a
“daemon”,
react
whenever
necessary;
− as
the
models
change,
the
system
can
react
instantly,
since

everything
needed
is
there
in
the
RETE
network:
no
re-‐
computa/on
is
necessary.

 Paper
at
ICMT2008:
Live
model
transforma:ons
driven

by
incremental
pa3ern
matching.
38


Change-driven transformations
 Generalization of the live transformation approach
 New formalism supports more precise change queries
− To distinguish between various execution trajectories that
result in the same net change
− A more complete adaptation of the ECA approach to graph
transformations
 Application scenarios
− Incremental model synchronization for non-materialized
models (paper at MODELS2009: Change-driven
transformations)
− Back-annotation of simulation traces (paper at SEFM2010)

39


Constraint satisfaction over models
 Motivation
− Very pragmatic problem area: constraint evaluation, “quick fix”
computation, design or configuration-space exploration etc.
− CLP(FD) limited: only finite problems can be formulated
● Problematic: object birth-and-death
− CLP(FD) difficult to use
 GT-based approaches
− Easier-to-use formalism
− Infinite (dynamic) problems
− “Traditional” problem: scalability 
 Our aim: combine ease-of-use and flexibility with
performance

40


CSP(M)
 Described by (M0,C,G,L) Performance
− M0 initial model (typed graph)  “Pure” and “Flexible” CSP(M)
− C set of global constraints (graph − Execution times significantly faster
patterns) than KORAT or GROOVE
− G set of goals (graph patterns)  Dynamic CSP(M)
− L set of labeling rules (GT rules) − We can even beat Prolog CLP(FD)
 Goal: Find a model Ms which in some cases 
satisfies all global constraints and  In general
goals (One, All, Optimal solutions) − VERY problem specific results
 Extensions − Lots of potential for future research
− Flexible CSP
● Strong-weak constraints
● Quality metrics
− Dynamic CSP: Add-remove
constraints, goals, labeling rules on-the-
fly
● Re-use already traversed state
space

41


Stochastic simulation by graph transformation
 Joint work with prof. Reiko Heckel’s group (University of
Leicester)
 Conceptually similar to the CSP engine
− Simulation rule: precondition + transformation
− Assign probability distributions to simulation rules
− Execute as-long-as-possible
− Observe system state changes
 Papers
− FASE2010: P. Torrini, R. Heckel, I. Ráth: Stochastic simulation of graph
transformation systems
− GT-VMT2010: P. Torrini, R. Heckel, I. Ráth, G. Bergmann: Stochastic
graph transformation with regions
− ASMTA2010: A. Khan, P. Torrini, R. Heckel and I. Ráth: Model-based
stochastic simulation of P2P VoIP using graph transformation

42


Applications
 VoIP P2P network behavioral simulation (Skype)
 Other simulation scenarios
− Social networks
− Traffic networks
− Crystal growth
 Evaluation
− +: Scales well (comparable to dedicated simulators)
− +: GT is a high-level behavioral specification formalism that is
easy-to-use
− -: does not (yet) support certain topological constraints (e.g.
transitive closure)

43


Summary of VIATRA
 VIATRA: provides a rule and pattern-based language
for uni-directional model transformations
 Main concepts
− multi-level metamodeling + model space
− transformation language
● graph transformation
● abstract state machines
− template-based code generation.
 Added value:
− Rich specification language
− Advanced and extensible execution strategies
− Usable for tool integration problems in practice

44


VIATRA2 IN TOOL
INTEGRATION

45


Main Application Fields
 Analysis of Business Process Models  SOA
− Verification by MC, Fault simulation, − Performance & Availability analysis
Security analysis − Configuration generation
(Bell-LaPadula) − Service Analysis and Deployment
− Optimization (ILog Solver) descriptor generation
 IBM Faculty Awards − Verification by MC (BPEL2SAL and
 MDD in the Enterprise back)
− Incremental correspondence  SA Forum + SENSORIA IP
maintenance between Requirements  Embedded Systems
models and − PIM & PSM for dependable embedded
● Architecture models systems
● Design models − PIM & PSM model store
− Change impact analysis − PIM-to-PSM mapping
 SecureChange IP − PIM & PSM validation
 Domain-specific modeling languages − Middleware code generation
− Design and transformation of domain − Test generation using SAL-ATG
specific languages − Valid PSM generation based on
− Model simulation and stochastic constraints ( CSP(M))
simulation ( GraSS)  DECOS, DIANA, MOGENTES IP
− Model-based generation of graphical
user interfaces

46


Summary
 Tool integration by precise model transformations: feasible in
− Service-oriented applications
− Dependable embedded systems
− Enterprise applications
 Transformations can be specified by a combination of formal
techniques
− Graph transformation
− Abstract State Machines
 MDD tools
− Can be built on open tool platforms
− Integrate a large set of tools
 Our approach
− Open, customizable
− Highly adaptive (new modeling standards, platforms, V&V tools, …)

47


Many thanks to
D. Varró, G. Bergmann, Á. Horváth, Á. Hegedüs, Z. Ujhelyi, G. Varró
A. Pataricza, A. Balogh, L. Gönczy, B. Polgár, D. Tóth
Z. Balogh, A. Ökrös, Zs. Déri
And many more students

THANK YOU FOR YOUR
ATTENTION

48

Model transformations in the VIATRA2 framework

Model transformations in the VIATRA2 framework

Recomendados

Más contenido relacionado

Was ist angesagt?

Was ist angesagt?(20)

Similar a Model transformations in the VIATRA2 framework

Similar a Model transformations in the VIATRA2 framework(20)

Más de Istvan Rath

Más de Istvan Rath(20)

Último

Último(20)

Model transformations in the VIATRA2 framework