Live model transformations can be driven incrementally by detecting changes to the matching set of patterns over the model. The VIATRA implementation uses RETE networks to efficiently maintain and update the matching sets when models change. This enables live transformations to respond instantly to modifications by mapping only the changes to the target model. Future work aims to improve performance further and enhance the language for debugging and static analysis of live transformations.

1. Live model transformations driven
Live model transformations driven
by incremental pattern matching
y p g
István Ráth (rath@mit.bme.hu)
Gábor Bergmann
András Ökrös
Dániel Varró
Budapest U i
B d t University of T h l
it f Technology and Economics
dE i ICMT, July 2, 2008
ICMT J l 2 2008

2. Overview
• I t d ti
Introduction
• Live transformations
• The VIATRA implementation
• Future work
• Summary

3. INTRODUCTION

4. Model transformations and
incrementality
• K
Key usage scenarios for MT:
i f MT
– Mapping between languages or various levels of abstraction
– Intra‐domain model manipulation
• Working with evolving models
– Constant changes & modifications
– Large models
g
• Problem: (re)transformations are slow
– To execute… (large models)
– and to re‐execute again and again (batch execution)
and to re‐execute again and again (batch execution).
• Solution: incrementality
– Take the source model, and its mapped counterpart;
– U h i f
Use the information about how the source model was changed;
i b h h d l h d
– Map and apply the changes (but ONLY the changes) to the target
model.

5. Towards incrementality
Towards incrementality
• How to achieve incrementality?
– Incremental updates: avoid re‐generation.
p g
• Don’t recreate what is already there.
• Use reference (correspondence) models.
Use reference (correspondence) models.

6. Incremental updates
Incremental updates
modification
S1 S2 S3 Sn
t tR tR tR
merge
T1 T2 T3 Tn

7. Towards incrementality
Towards incrementality
• How to achieve incrementality?
– Incremental updates: avoid re‐generation.
p g
• Don’t recreate what is already there.
• Use reference (correspondence) models.
Use reference (correspondence) models.
– Incremental execution: avoid re‐computation.
• Don’t recalculate what was already computed
Don t recalculate what was already computed.
• How?

8. Live transformations
Live transformations 0
modification
S1 S2 S3 Sn
t tL transformation tL tL
context
update
T1 T2 T3 Tn
0Hearnden‐Lawley‐Raymond. Incremental Model Transformation for the Evolution of
Model‐driven Systems. MODELS 2006.

9. Live transformations?
Live transformations?
• E
Essentially: a different execution mode.
ti ll diff t ti d
– More than “simple” incremental execution…
• Run as “daemons”
Run as daemons
– whenever model changes occur
• Maintain a transformation context
Maintain a transformation context
– To persist (cache) the execution state
• Model changes can be instantly mapped
– Input
• what has changed (creation, deletion)
• where has the change occurred (source reference target)
has the change occurred (source, reference, target)
– Output:
• actions (what to do)

10. Possible applications
Possible applications
• M2M / inter‐domain transformations
/i d i f i
– Model synchronization on‐the‐fly
• M2M / intra‐domain transformations
– Model animation/execution (based on dynamic
Model animation/execution (based on dynamic
semantics)
– Constraint checking on‐the‐fly (what‐if)
Constraint checking on the fly (what if)
• M2C
–I
Incremental model‐code synchronization (DSMLs)
t l d l d h i ti (DSML )
• ...

11. GRAPH TRIGGERS IN VIATRA2

12. Graph transformations
Graph transformations
• Graph rewriting based on rules
h ii b d l
• Driven by graph patterns
yg p p
– Subgraph to be matched in the model graph
– A set of constraints (type, attribute value,
A set of constraints (type, attribute value,
structural, …)
• Execution
– Declarative approaches (GT rules, TGG)
–IImperative (mixed) approaches (explicit control
ti ( i d) h ( li it t l
flow)

13. Incremental graph pattern matching
Incremental graph pattern matching
• Graph transformations require pattern
matchingg
• Goal: retrieve the matching set quickly
• H ?
How?
– Store (cache) matchings execution context
– Update them as the model changes
– Update precisely incrementality
Update precisely

14. Core idea: use RETE1 nets
• RETE network INPUT
– node: (partial) matches of a
node: (partial) matches of a
(sub)pattern
t3 Model space
Model space p1 p2 p3 t1 t2 k1 k2 t3
– edge: update propagation t3 t3 t3
• Demonstrating the principle
Demonstrating the principle
– input: Petri net Input nodes
: Place
p1 p2 p3
d : Token
k1 k2
: Transition
t1 t2 t3
– pattern: fireable transition
– Model change: new transition
t3
(t3)
p1
t1 Intermediate
p1, k1 p2, k2
p3 p2
nodes p1, k1, t1 p2, k2, t3
t2
p2, k2, t3
t3
1 Forgy, C.L.: RETE: A fast algorithm for Production node
Production node
p1, k1, t1, p3 p2, k2, t2, p3
the many pattern/many object pattern
match problem. AI 1982.

15. Updates
• N d d h
Needed when the model space changes
h d l h
• VIATRA notification mechanism (EMF is also possible)
– Transparent: user modification, model imports, results of a
transformation, external modification, … RETE is always
updated!
• Input nodes receive elementary modifications and
release an update token
p
– Represents a change in the partial matching (+/‐)
• Nodes process updates and propagate them if needed
p p p p g
– PRECISE update mechanism

16. Event‐driven live transformations
Event driven live transformations
An idea: represent events as model elements.2
• A id t t d l l t
• Our take: represent events as changes in the matching
set of a pattern.
set of a pattern
– ~generalization
• Incrementality: persistent context
y p
– matching sets cached in RETE networks efficiency!
– global cache (“session”)
• Formalism
– Specify WHEN and HOW to (re)act
– Sh ld b “MT lik ”
Should be “MT‐like”
2E. Guerra – J. de Lara. Event‐Driven Grammars: Towards the Integration of Meta‐
modelling and Graph Transformation, 2004

17. Formalism
@trigger(sensitivity=“rise”, priority=“1”, mode=“always”)
@ i ( i i i “ i ” i i “ ” d “ l ”)
gtrule mapClass() =
{ Graph transformation rule
High level support for:
precondition pattern pre(C) = { class(C); } marked as a live transformation
‐ Model element creation/deletion Annotations to specify execution
postcondition pattern post(C,T) = { unit (trigger)
‐ Attribute value changes (special modes
d
Table(T);
language constructs)
mapping(M,C,T); Precondition pattern: defines
} ‐ Arbitrarily complex changes
Arbitrarily complex changes the graph pattern whose
the graph pattern whose
(involving multiple model elements) matching set changes trigger
action { the execution
‐ Model changes from any source
g
rename(T, name(C)); y Postcondition pattern:
pattern:
(user editing, transformations, model describes how the model is to
debug(“Table created: “ + fqn(T));
Action sequence: imperative
imports, …) be changed declaratively
model modification, debug
}
printing, code generation, …
i i d i
}

18. Execution
Transaction1 Commit Transaction2
Matching set delta monitor
trigger
fall
PA actions
Execution
Engine
Interesting questions:
PB rise
‐ Serialization (priority
ordering, conflicts, race Trigger
queue
q e e
conditions) Incre‐
‐ Parallel execution mental
PM

19. APPLICATIONS & FUTURE WORK

20. Case studies
Case studies
• Domain‐specific visual languages (ViatraDSM)
– Incremental, on‐the‐fly constraint evaluation
, y
(&enforcement) ‐‐ VIATRA2 is not limited to the
„source target” scenario
– On‐the‐fly abstract‐concrete synchronization
On the fly abstract concrete synchronization
‐‐ can be used to map a DSML into
• Metamodel‐driven, based on GMF specification models
multiple concrete syntax
representations (analysis models,
p ( y
– Incremental code generation
Incremental code generation architectural models, etc)
simultaneously, on multiple levels of
• Model‐code synchronization
abstraction
– Model animation & simulation3
3Ráth‐Vágó‐Varró. Design‐time simulation of domain‐specific models by incremental
pattern matching. Accepted for VL/HCC 2008.

21. Performance4
Object-Relational Mapping
100000
10000
cution time [ms]
build
b ild – VIATRA/RETE
sync – VIATRA/RETE
1000
build – VIATRA/LS
‐‐ Sub‐1000ms execution time for UML
sync – VIATRA/LS
models < 5000 nodes
d l 5000 d
Exec
100 ‐‐ Low‐order‐polynomial characteristics
(compared to exponential with local
search)
10
‐‐ Acceptable execution time (n.10s) for
10 100 1000 really large models (100000+)
10000 100000
Model size [node count]
4Bergmann‐Horváth‐Ráth‐Varró. A benchmark evaluation of incremental pattern
matching in graph transformation. To appear in Proc. ICGT2008.

22. Future work
Future work
• I
Improving performance
i f
– Parallel (multi‐core) execution
– RETE optimizations
RETE optimizations
• Language improvements
– More compact notations
More compact notations
– Static type checking
– Debugging support
Debugging support
• EMF support
– Incremental pattern matching & matching set
Incremental pattern matching & matching set
detection (EMFT)
– Java API based on the VIATRA language

23. Conclusion
• Live transformation engine for incremental graph
i f i i f i l h
transformations
– Novel approach based on matching set changes,
supported by the new, high performance incremental
pattern matching engine
pattern matching engine
• VIATRA2 R3
– htt // li
http://eclipse.org/gmt
/ t
– http://wiki.eclipse.org/VIATRA2
– A il bl
Available as a preview release (coming in August)
i l ( i i A )
• Thank you.