Invited talk for the Generative Software Development Lab at the University of Waterloo, Ontario, Canada, late 2010.

1. Applica'ons
of
incremental
pa1ern
matching
in
model
transforma'ons
István
Ráth
(rath@mit.bme.hu)
Budapest
University
of
Technology
and
Economics
Budapest
University
of
Technology
and
Economics
Department
of
Measurement
and
Informa<on
Systems
1

2. Overview
 Introduc'on
o VIATRA2
o Incremental
graph
pa1ern
matching
 Part
I:
The
impact
on
performance
o Early
benchmarks
and
improvements
o EMF-­‐INCQuery
 Part
II:
Beyond
performance
o Event-­‐driven
and
change-­‐driven
transforma'ons
o Constraint
sa'sfac'on
solving
over
models
–
CSP(M)
o Model
simula'on
by
stochas'c
graph
transforma'ons
 Future
research
direc'ons
2

3. About
me
 h1p://mit.bme.hu/~rath
 I
am
o a
soRware
engineer
graduated
in
2006
o a
PhD
candidate
at
BUTE,
hope
to
finish
this
year
o a
fan
and
supporter
of
Eclipse
 I’ve
been
working
o with
Dr.
Dániel
Varró
since
2004
o as
a
VIATRA2
developer
and
enthusiast

o also
as
the
chief
architect
and
development
coordinator
in
the
VIATRA2
project
o In
various
other
industrial
projects
too
3

4. INTRODUCTION
Graph
Transforma'ons
from
the
VIATRA2
perspec've…
4

5. VIATRA2
is…
 A
graph
transforma'on
tool
o h1p://eclipse.org/gmt/VIATRA2
o h1p://wiki.eclipse.org/VIATRA2
o h1p://viatra.inf.mit.bme.hu
 A
project
o Lead
by
Dr.
Dániel
Varró
at
BUTE’s
Fault
Tolerant
Systems
Research
Group
o Started
in
1998
with
the
original
VIATRA
o Current
tech:
since
2004
o Many
PhD,
grad
and
undergrad
par'cipants
over
the
years
o Current
team:
2
seniors,
2
PhD
candidates,
3
PhD
students,
7
students
 A
technology
o Industrial
development
partner:
OptXware
Ltd.
o Has
been
experimented
with
in
various
(academic
and
industrial)
organiza'ons
world-­‐wide
5

6. Applica'ons
of
VIATRA2
 “Stand-­‐alone”
model
transforma'ons
 Early
analysis
(DECOS,
SecureChange)
 Integrated
features
for
graphical
DSMLs
(ViatraDSM)
 Model
execu'on/analysis
(stochas'c
GT)
 (Development)
tool
integra'on
(DECOS,
SENSORIA,
MOGENTES)
 Model
op'miza'on
/
constraint
solving
(DIANA)
6

7. 7
Metamodeling
1
tokens Place
1
* outarc1
Metamodel
Token
inarc
* *
Transition
Instance model
t1:Transition
a4:outarc a3:inarc
p1:Place p3:Place
a1:inarc a2:outarc
tkn3:tokens
to1:Token t2:Transition
7

8. 7
Metamodeling
Class
At most one 1
tokens Place
1
Association
* outarc1
Metamodel
Token Multiplicity
inarc
* *
constraint
Arbitrary
Slot Transition
Instance model
t1:Transition Object
a4:outarc a3:inarc
p1:Place Link p3:Place
a1:inarc a2:outarc
tkn3:tokens
to1:Token t2:Transition
7

9. 8
Graph
Transforma'on
LHS RHS
a1:inarc a2:outarc a1:inarc a2:outarc
Place Tran. Place Place Tran. Plan
ttn1:tokens tkn2:tokens
Token Token
Phases of GT matching
– Pattern Matching phase
– Updating phase: delete+ create
8

10. 8
Graph
Transforma'on
LHS RHS
a1:inarc a2:outarc a1:inarc a2:outarc
Place Tran. Place Place Tran. Plan
ttn1:tokens tkn2:tokens
Token Token
matching
Phases of GT matching
– Pattern Matching phase
– Updating phase: delete+ create
8

11. 8
Graph
Transforma'on
LHS RHS
a1:inarc a2:outarc a1:inarc a2:outarc
Place Tran. Place Place Tran. Plan
ttn1:tokens tkn2:tokens
Token Token
matching updating
Phases of GT matching
– Pattern Matching phase
– Updating phase: delete+ create
Pattern Matching is the most critical issue from performance viewpoint
8

12. Incremental
model
transforma'ons
 Key
usage
scenarios
for
MT:
o Mapping
between
languages
o Intra-­‐domain
model
manipula;on
• Model
execu;on
• Validity
checking
(constraint
evalua;on)
 They
work
with
evolving
models.
o Users
are
constantly
changing/modifying
them.
o Users
usually
work
with
large
models.
 Problem:
transforma;ons
are
slow
o To
execute…
(large
models)
o and
to
re-­‐execute
again
and
again
(always
star;ng
from
scratch).
 Solu;on:
incrementality
o Take
the
source
model,
and
its
mapped
counterpart;
o Use
the
informa;on
about
how
the
source
model
was
changed;
o Map
and
apply
the
changes
(but
ONLY
the
changes)
to
the
target
model.
9

13. Towards
incrementality
 How
to
achieve
incrementality?
o Incremental
updates:
avoid
re-­‐genera'on.
• Don’t
recreate
what
is
already
there.
•  Use
reference
(correspondence)
models.
o Incremental
execu+on:
avoid
re-­‐computa'on.
• Don’t
recalculate
what
was
already
computed.
• How?
10

14. Towards
incrementality
 How
to
achieve
incrementality?
o Incremental
updates:
avoid
re-­‐genera'on.
• Don’t
recreate
what
is
already
there.
•  Use
reference
(correspondence)
models.
o Incremental
execu+on:
avoid
re-­‐computa'on.
• Don’t
recalculate
what
was
already
computed.
• How?
10

15. INCREMENTAL
GRAPH
PATTERN
MATCHING
11

16. Incremental
graph
pa1ern
matching
 Graph
transforma;ons
require
paQern
matching
o Most
expensive
phase
  Goal:
retrieve
the
matching
set
quickly
 How?
o Store
(cache)
matches
o Update
them
as
the
model
changes
• Update
precisely
 Expected
results:
good,
if…
o There
is
enough
memory
(*)
o Queries
are
dominant
o Model
changes
are
rela;vely
sparse
(**)
o e.g.
synchroniza;on,
constraint
evalua;on,
…
12

17. Opera'onal
overview
XForm
pa1ern
matching interpreter model
manipula'on
Incremental
VIATRA
pa1ern event
no'fica'on Model
space
matcher
updates
13

18. Core
idea:
use
RETE
nets
 RETE
network INPUT
o node:
(par;al)
matches
of
a
p1 p2 p3 t1 t2 k1 k2
(sub)paQern
o edge:
update
propaga;on
 Demonstra;ng
the
principle
:
Place :
Token :
Transi'on
o input:
Petri
net
p1 p2 p3 k1 k2 t1 t2
o paQern:
fireable
transi;on
o Model
change:
new
transi;on
(t3)
p1,
k1 p2,
k2
p1 t1
p1,
k1,
t1
p3 p2
t2
p1,
k1,
t1,
p3
14

19. Core
idea:
use
RETE
nets
 RETE
network
Model
space
INPUT
o node:
(par;al)
matches
of
a
p1 p2 p3 t1 t2 k1 k2
(sub)paQern
o edge:
update
propaga;on
 Demonstra;ng
the
principle
o input:
Petri
net
o paQern:
fireable
transi;on
Input
nodes
:
Place
p1 p2 p3
:
Token
k1 k2
:
Transi'on
t1 t2
o Model
change:
new
transi;on
(t3)
Intermediate
p1,
k1 p2,
k2
t1
p1
nodes p1,
k1,
t1
p3 p2
t2
Produc;on
node
p1,
k1,
t1,
p3
14

20. Core
idea:
use
RETE
nets
 RETE
network INPUT
o node:
(par;al)
matches
of
a
p1 p2 p3 t1 t2 k1 k2
(sub)paQern
o edge:
update
propaga;on
 Demonstra;ng
the
principle
:
Place :
Token :
Transi'on
o input:
Petri
net
p1 p2 p3 k1 k2 t1 t2
o paQern:
fireable
transi;on
o Model
change:
new
transi;on
(t3)
p1,
k1 p2,
k2
p1 t1
p1,
k1,
t1
p3 p2
t2
p1,
k1,
t1,
p3
14

21. Core
idea:
use
RETE
nets
 RETE
network INPUT
o node:
(par;al)
matches
of
a
t3
p1 p2 p3 t1 t2 k1 k2
(sub)paQern
o edge:
update
propaga;on
 Demonstra;ng
the
principle
:
Place :
Token :
Transi'on
o input:
Petri
net
p1 p2 p3 k1 k2 t1 t2
o paQern:
fireable
transi;on
o Model
change:
new
transi;on
(t3)
p1,
k1 p2,
k2
p1 t1
p1,
k1,
t1
p3 p2
t2
p1,
k1,
t1,
p3
t3
14

22. Core
idea:
use
RETE
nets
 RETE
network INPUT
o node:
(par;al)
matches
of
a
t3
p1 p2 p3 t1 t2 k1 k2 t3
(sub)paQern
o edge:
update
propaga;on t3 t3 t3
 Demonstra;ng
the
principle
:
Place :
Token :
Transi'on
o input:
Petri
net
p1 p2 p3 k1 k2 t1 t2
o paQern:
fireable
transi;on
o Model
change:
new
transi;on
(t3)
p1,
k1 p2,
k2
p1 t1
p1,
k1,
t1
p3 p2
t2
p1,
k1,
t1,
p3
t3
14

23. Core
idea:
use
RETE
nets
 RETE
network INPUT
o node:
(par;al)
matches
of
a
t3
p1 p2 p3 t1 t2 k1 k2 t3
(sub)paQern
o edge:
update
propaga;on t3 t3 t3
 Demonstra;ng
the
principle
:
Place :
Token :
Transi'on
o input:
Petri
net
p1 p2 p3 k1 k2 t1 t2 t3
o paQern:
fireable
transi;on
o Model
change:
new
transi;on
(t3) t3
p1,
k1 p2,
k2
p1 t1
p1,
k1,
t1
p3 p2
t2
p1,
k1,
t1,
p3
t3
14

24. Core
idea:
use
RETE
nets
 RETE
network INPUT
o node:
(par;al)
matches
of
a
t3
p1 p2 p3 t1 t2 k1 k2 t3
(sub)paQern
o edge:
update
propaga;on t3 t3 t3
 Demonstra;ng
the
principle
:
Place :
Token :
Transi'on
o input:
Petri
net
p1 p2 p3 k1 k2 t1 t2 t3
o paQern:
fireable
transi;on
o Model
change:
new
transi;on
(t3) t3
p1,
k1 p2,
k2
p1 t1
p1,
k1,
t1 p2,
k2,
t3
p3 p2
t2 p2,
k2,
t3
p1,
k1,
t1,
p3
t3
14

25. Core
idea:
use
RETE
nets
 RETE
network INPUT
o node:
(par;al)
matches
of
a
t3
p1 p2 p3 t1 t2 k1 k2 t3
(sub)paQern
o edge:
update
propaga;on t3 t3 t3
 Demonstra;ng
the
principle
:
Place :
Token :
Transi'on
o input:
Petri
net
p1 p2 p3 k1 k2 t1 t2 t3
o paQern:
fireable
transi;on
o Model
change:
new
transi;on
(t3) t3
p1,
k1 p2,
k2
p1 t1
p1,
k1,
t1 p2,
k2,
t3
p3 p2
t2 p2,
k2,
t3
p1,
k1,
t1,
p3 p2,
k2,
t2,
p3
t3
14

26. RETE
network
construc'on
 Key:
paQern
decomposi;on
o PaQern
=
set
of
constraints
(defined
over
paQern
variables)
o Types
of
constraints:
type,
topology
(source/target),
hierarchy
(containment),
aQribute
value,
generics
(instanceOf/supertypeOf),
injec+vity,
[nega;ve]
paQern
calls,
…
 Construc;on
algorithm
(roughly)
o 1.
Decompose
the
paQern
into
elementary
constraints
(*)
o 2.
Process
the
elementary
constraints
and
connect
them
with
appropriate
intermediate
nodes
(JOIN,
MINUS-­‐JOIN,
UNION,
…)
o 3.
Create
terminator
produc;on
node
15

27. Key
RETE
components
 JOIN
node INPUT
INPUT INPUT
o ~rela'onal
algebra:
natural
join
JOIN
 MINUS-­‐JOIN
JOIN
o Nega've
existence
(NACs) PRODUCTION
sourcePlace
16

28. Suppor'ng
a
rich
pa1ern
language
 PaQern
calls
o Simply
connect
the
produc;on
nodes
o  PaQern
recursion
is
fully
supported
 OR-­‐paQerns
o UNION
intermediate
nodes
 Check
condi;ons
o check
(value(X)
%
5
==
3)
o check
(length(name(X))
<
4)
o check
(myFunction(name(X))!=‘myException’)
o 
Filter
and
term
evaluator
nodes
 Result:
full
VIATRA
transforma;on
language
support;
any
paQern
can
be
matched
incrementally.
17

29. Updates
 Needed
when
the
model
space
changes
 VIATRA
no;fica;on
mechanism
(EMF
is
also
possible)
o Transparent:
user
modifica;on,
model
imports,
results
of
a
transforma;on,
external
modifica;on,
…
 RETE
is
always
updated!
 Input
nodes
receive
elementary
modifica;ons
and
release
an
update
token
o Represents
a
change
in
the
par;al
matching
(+/-­‐)
 Nodes
process
updates
and
propagate
them
if
needed
o PRECISE
update
mechanism
18

30. PART
I:
IMPACT
ON
PERFORMANCE
19

31. 20
Benchmarking
in
graph
transforma;on
 Specifica'on
examples
for
GT
o Goal:
assessing
expressiveness
o UML-­‐to-­‐XMI,
object-­‐rela'onal
mapping,
UML-­‐to-­‐EJB,
etc.
 „Generic”
Performance
benchmarks
for
GT
o Varró
benchmark
o R.
Geiß
and
M.
Kroll:
On
Improvements
of
the
Varró
Benchmark
for
Graph
Transforma<on
Tools
o (Ag<ve
Tool
Contest,
Grabats
’08,
…)
 Our
ICGT’08
paper:
Benchmarks
for
graph
transformaNon
with
incremental
paPern
matching
20

32. Ini'al
benchmarking:
summary
 Benchmarking
scenarios
focused
on
o “tradi'onal”
MT
use
cases
such
as
model
synchroniza'on
o Addi'onal
use
cases
where
INC
expected
to
be
very
good
(e.g.
model
execu'on,
constraint
evalua'on)
 Predictable
near-­‐linear
growth
o As
long
as
there
is
enough
memory
o Certain
problem
classes:
constant
execu'on
'me

 Some
benchmark
example
descrip'ons,
specifica'ons,
and
measurement
results
available
at:
o hPp://wiki.eclipse.org/VIATRA2/Benchmarks
21

33. Further
improvements
 Parallelism
o Update
the
RETE
network
in
parallel
with
the
transforma'on
o Support
parallel
transforma'on
execu'on
o Paper
at
GT-­‐VMT’09:
Paralleliza'on
of
Graph
Transforma'on
Based
on
Incremental
Pa1ern
Matching
 Hybrid
pa1ern
matching
o „mix”
pa1ern
matching
strategies,
use
each
at
its
best
o Paper
at
ICMT’09:
Efficient
model
transforma'ons
by
combining
pa1ern
matching
strategies
22

34. Parallelism:
lessons
learned
 Can
be
good
AND
bad
for
performance
 Cannot
be
easily
automated
 VERY
problem
specific!
 Ongoing
research:
true
parallel
GT
execu'on
o “High”
level
specifica'on
language
• Supports
locking
and
synchroniza'on
23

35. Hybrid
PM:
lessons
learned
 Paper
for
a
special
issue
in
STTT’09:
Experimental
assessment
of
combining
pa1ern
matching
strategies
with
VIATRA2
 In
short:
you
may
get
a
linear
decrease
in
memory
for
a
linear
increase
in
execu'on
'me
 retains
complexity
class
characteris'cs 
24

36. EMF-­‐INCQUERY
Incremental
pa1ern
matching
beyond
VIATRA2
25

37. Mo'va'on
 VIATRA2
has
lacked
generic
EMF
support
o Even
though
UML2
and
some
other
EMF-­‐based
languages
are
supported
o This
is
expected
to
change
(for
the
be1er)
with
Release4

 Main
reason:
large
conceptual
gaps
between
model
representa'on
o N-­‐level
metamodeling
(VPM)
vs.
MOF-­‐style
(EMF)
o Graph
structures
(VPM)
vs.
A1ributed
nodes
(EMF)
o Dynamic
typing
(VPM)
vs.
Sta'c
(genera've)
types
(EMF)
o Mul'-­‐domain
modelspace
(VPM)
vs.
domain-­‐specific
resources
(EMF)
26

38. Goals
 EMF
lacks
a
fast
query
engine
o MDT-­‐OCL,
EMF
Query
do
not
scale
well
 Goal
1:
port
incremental
PM
technology
to
EMF
o Fast,
effec've
model
queries
o Easy-­‐to-­‐use
declara've
API
(graph
pa1erns)
o Support
for
on-­‐the-­‐fly
constraint
evalua'on
and
other
scenarios
 Goal
2:
generic
EMF
support
for
VIATRA2
R3.x
o Reflec've
and
genera've
model
export-­‐import
27

39. EMF-­‐IncQuery:
overview
 At
run'me
o Incremental
pa1ern
matching
engine
for
EMF
models
o Uses
the
EMF
No'fica'on
API
for
updates
o Works
with
any
transac'on-­‐based
EMF
applica'on
• Minor
modifica'on
necessary
o Supports
generic
as
well
as
parameterized
model
queries
o Supports
VIATRA2’s
rich
declara've
pa1ern
language
(recursion,
composi'on,
a1ribute
constraints…)
o No
VIATRA2
dependency
 As
tooling
o Genera've:
compiles
queries
into
RETE
networks
(vs.
VIATRA2’s
dynamic
approach)
o Relies
on
VIATRA2
for
query
development
and
debugging
28

40. Architecture
29

41. Evalua'on
 (To
be)
Presented
at
MODELS2010
o Gábor
Bergmann,
Ákos
Horváth,
István
Ráth,
Dániel
Varró:
Incremental
Evalua'on
of
Model
Queries
over
EMF
Models
o Case
study:
AUTOSAR
on-­‐the-­‐fly
constraint
evalua'on
• Simple
and
complex
constraints
o Compared
to:
• MDT-­‐OCL
• EMF
Query
• Ad-­‐hoc
Java
implementa'on
30

42. Performance
31

43. Summary
 Several
orders
of
magnitude
faster
than
the
state-­‐of-­‐the-­‐
art
o Constraint
re-­‐evalua'on:
nearly
constant
execu'on
'mes
 Price
of
performance:
memory
consump'on
o Grows
linearly
with
the
model
size
(even
for
complex
constraints)
o To
be
addressed
in
future
work
 Addi'onal
future
work
o Accept
(a
subset
of)
OCL
as
input
for
queries
 Will
be
available
as
open
source
o h1p://viatra.inf.mit.bme.hu/models10
32

44. Future
research
targets
 Keyword
#1:
scalability
oModel
size
oQuery/transforma;on
complexity
oReal
;me
applica;ons
 Keyword
#2:
teamwork
oCo-­‐opera;ve
modeling
repositories
oConflict
detec;on
&
resolu;on
33

45. Scalability
challenges
 VIATRA2,
EMF,
…
hit
the
limit
at
a
few
(1-­‐5)
million
model
elements
in-­‐memory
o Compiled
model
transformers
do
somewhat
be1er
on
synthe+c
benchmarks
o But:
compiled
approaches
reduce
flexibility
(dynamic
typing,
untyped
elements,
mul'-­‐domain
modeling,
…)
 Increasing
demand
for
handling
really
large
models
o AUTOSAR:
15-­‐30+
million
elements
 Transforma'on
complexity
is
growing
o As
MT
gains
more
industrial
exposure
o Problem
areas:
re-­‐use
(libraries),
design
pa1erns,
execu'on
infrastructure,
specifica'on
complexity
…
34

46. Teamwork
(and
other)
challenges
 Painful
problems
in
DSML
prac'ce
o Metamodel
evolu'on
o Model
comparison,
versioning,
conflict
resolu'on,
merge
o Concurrent
teamwork,
collabora've
modeling,
…
 EMF
lags
behind
o Even
though
the
EMF
ecosystem
is
huge
 Many
of
these
problems
are
VERY
hard
(to
solve
well)
o No
“silver
bullet”
solu'on
yet
35

47. Our
vision
Model
space
Collabora'
ve
client-­‐ Par''on
Par''on
Par''on
Na've
Na've
server
(EMF) (UML) (RDF) persistence
Na've
persistence
persistence
access
High
performance
INC
transforma'on
engine
Language
adapters
VIATRA ATL QVT
36

48. Our
vision
Model
space
Collabora'
ve
client-­‐ Par''on
Par''on
Par''on
Na've
Na've
server
(EMF) (UML) (RDF) persistence
Na've
persistence
persistence
access No
need
for
model
export-­‐
import
High
performance
INC
transforma'on
engine
Language
adapters
VIATRA ATL QVT
36

49. Our
vision
Model
space Out-­‐of-­‐memory
Collabora' model
storage
ve
client-­‐ Par''on
Par''on
Par''on
Na've
Na've
server
(EMF) (UML) (RDF) persistence
Na've
persistence
persistence
access No
need
for
model
export-­‐
import
High
performance
INC
transforma'on
engine
Language
adapters
VIATRA ATL QVT
36

50. Our
vision
Model
space Out-­‐of-­‐memory
Collabora' model
storage
ve
client-­‐ Par''on
Par''on
Par''on
Na've
Na've
server
(EMF) (UML) (RDF) persistence
Na've
persistence
persistence
access No
need
for
model
export-­‐
import
High
performance
INC
transforma'on
engine
Acts
as
a
“common
Language
adapters
VIATRA ATL QVT
run'me”
36

51. Our
vision
Model
space Out-­‐of-­‐memory
Collabora' model
storage
ve
client-­‐ Par''on
Par''on
Par''on
Na've
Na've
server
(EMF) (UML) (RDF) persistence
Na've
persistence
persistence
access No
need
for
Supports
model
export-­‐
distributed
import
models
and
High
performance
versioning INC
transforma'on
engine
Acts
as
a
“common
Language
adapters
VIATRA ATL QVT
run'me”
36

52. Our
vision
Model
space Out-­‐of-­‐memory
Collabora' model
storage
ve
client-­‐ Par''on
Par''on
Par''on
Na've
Na've
server
(EMF) (UML) (RDF) persistence
Na've
persistence
persistence
access No
need
for
Supports
model
export-­‐
distributed
import
models
and
High
performance
versioning INC
transforma'on
engine Adap've
IPM
Acts
as
a
engine
(lower
“common
Language
adapters memory
run'me” VIATRA ATL QVT footprint)
36

53. PART
II:
BEYOND
PERFORMANCE
37

54. What
really
is
INC?
 Graph
pa1erns
~
complex
constraint
sets
o Matching
set:
overlay
of
“valid”
elements
 RETE:
a
complex
overlay
cache
of
the
model
graph
o Stores
matching
sets
explicitly
 A
historical
cache
o Can
store
“previous”
overlay
states
38

55. What
really
is
INC?
 Graph
pa1erns
~
complex
constraint
sets
o Matching
set:
overlay
of
“valid”
elements
 RETE:
a
complex
overlay
cache
of
the
model
graph
o Stores
matching
sets
explicitly
 A
historical
cache
o Can
store
“previous”
overlay
states
38

56. Idea
 Use
the
historical
overlay
to
o Easily
compute
non-­‐trivial
change
informa'on
(beyond
elementary
changes)
• Detect
high-­‐level
“events”
• Detect
(the
net
effect
of)
complex
change
sequences
o Assign
ac'ons
to
these
changes
• Event-­‐Condi'on-­‐Ac'on
formalism
in
rule-­‐based
systems
• 
event-­‐driven
transforma'ons
o Or,
easily
track
the
validity
set
of
constraints
as
the
model
is
evolving
• 
constraint
sa'sfac'on
solving
o Or,
easily
track
enabledness
condi'ons
for
simula'on
rules
• 
stochas'c
model
simula'on
39

57. Event-­‐driven
live
transforma'ons
 Represent
events
as
changes
in
the
matching
set
of
a
paQern.
o More
general
than
previous
approaches
 Live
transforma;ons
o maintain
the
context
(variable
values,
global
variables,
…);
o run
as
a
“daemon”,
react
whenever
necessary;
o 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
paQern
matching.
40

58. Change-­‐driven
transforma'ons
 Generaliza'on
of
the
live
transforma'on
approach
 New
formalism
supports
more
precise
change
queries
o To
dis'nguish
between
various
execu'on
trajectories
that
result
in
the
same
net
change
o A
more
complete
adapta'on
of
the
ECA
approach
to
graph
transforma'ons
 Applica'on
scenarios
o Incremental
model
synchroniza'on
for
non-­‐materialized
models
(paper
at
MODELS2009:
Change-­‐driven
transforma'ons)
o Back-­‐annota'on
of
simula'on
traces
(paper
at
SEFM2010)
41

59. Constraint
sa'sfac'on
over
models
 Mo'va'on
o Very
pragma'c
problem
area:
constraint
evalua'on,
“quick
fix”
computa'on,
design
or
configura'on-­‐space
explora'on
etc.
o CLP(FD)
limited:
only
finite
problems
can
be
formulated
• Problema'c:
object
birth-­‐and-­‐death
o CLP(FD)
difficult
to
use
 GT-­‐based
approaches
o Easier-­‐to-­‐use
formalism
o Infinite
(dynamic)
problems
o “Tradi'onal”
problem:
scalability

 Our
aim:
combine
ease-­‐of-­‐use
and
flexibility
with
performance
42

60. CSP(M)
 Described
by
(M0,C,G,L)
o M0
ini+al
model
(typed
graph)
o C
set
of
global
constraints
(graph
pa1erns)
o G
set
of
goals
(graph
pa1erns)
o L
set
of
labeling
rules
(GT
rules)
 Goal
o Find
a
model
Ms
which
sa'sfies
all
global
constraints
and
goals.
• One
model
• All
model
• Op'mal
model
43

61. Implementa'on
with
VIATRA2
 Incremental
constraint
evalua'on
by
incremental
pa1ern
matching
o Cached
matchings
o Incrementally
updated
 Simple
state
space
representa'on
 Typed
graph
comparison
o DSMDiFF
 Backtracking
o Transac'ons
of
atomic
manipula'on
opera'ons
44

62. Extensions
of
CSP(M)
 Flexible
CSP
o Strong-­‐weak
constraints
o Quality
metrics
 Dynamic
CSP
o Add-­‐remove
on-­‐the-­‐fly
• Global
constraints
• Goals
• Labeling
rules
o Re-­‐use
already
traversed
state
space
45

63. Current
state
of
CSP(M)
 “Pure”
and
“Flexible”
CSP(M)
o Execu'on
'mes
significantly
faster
than
KORAT
or
GROOVE
 Dynamic
CSP(M)
o We
can
even
beat
Prolog
CLP(FD)
in
some
cases

 In
general
o VERY
problem
specific
results
o Lots
of
poten'al
for
future
research
46

64. Stochas;c
simula;on
by
graph
transforma;on
 Joint
work
with
Reiko
Heckel’s
group
(University
of
Leicester)
 Papers
o FASE2010:
P.
Torrini,
R.
Heckel,
I.
Ráth:
Stochas'c
simula'on
of
graph
transforma'on
systems
o GT-­‐VMT2010:
P.
Torrini,
R.
Heckel,
I.
Ráth,
G.
Bergmann:
Stochas'c
graph
transforma'on
with
regions
o ASMTA2010:
A.
Khan,
P.
Torrini,
R.
Heckel
and
I.
Ráth:
Model-­‐based
stochas'c
simula'on
of
P2P
VoIP
using
graph
transforma'on
47

65. Idea
 Conceptually
similar
to
the
CSP
engine
o Simula'on
rule:
precondi'on
+
transforma'on
o Assign
probability
distribu'ons
to
simula'on
rules
o Execute
as-­‐long-­‐as-­‐possible
o Observe
system
state
changes
48

66. Applica'ons
 VoIP
P2P
network
behavioral
simula'on
(Skype)
 Other
simula'on
scenarios
o Social
networks
o Traffic
networks
o Crystal
growth
 Evalua'on
o +:
Scales
well
(comparable
to
dedicated
simulators)
o +:
GT
is
an
easier-­‐to-­‐use
specifica'on
formalism
49

67. FUTURE
50

68. Research
topics
overview
 Transforma'on
engineering
o Change-­‐driven
transforma'ons
o Sta'c
program
checking
for
transforma'ons
o Re-­‐factoring
and
composi'on
(transforma'on
chains)
o Model
transforma'on
by
example
o Semiautoma'c
back-­‐annota'on
for
dynamic
languages
o From
OCL
to
graph
pa1erns
and
back
 New
applica'ons
o Stochas'c
simula'on
o CSP(M)
 Scalability
o Very
large
models
o Collabora've
model
repositories
o Op'miza'on
of
the
IPM
engine
51