Live model transformations driven     Live model transformations driven     by incremental pattern matching      y        ...
Overview• I t d ti  Introduction• Live transformations• The VIATRA implementation• Future work• Summary
INTRODUCTION
Model transformations and                incrementality• K  Key usage scenarios for MT:                  i f MT   – Mappin...
Towards incrementality        Towards incrementality• How to achieve incrementality?  – Incremental updates: avoid re‐gene...
Incremental updatesIncremental updates      modification S1                  S2   S3   Sn  t                  tR   tR   tR...
Towards incrementality        Towards incrementality• How to achieve incrementality?  – Incremental updates: avoid re‐gene...
Live transformations                Live transformations 0                     modification               S1              ...
Live transformations?             Live transformations?• E  Essentially: a different execution mode.       ti ll     diff ...
Possible applications           Possible applications• M2M / inter‐domain transformations      /i      d   i       f     i...
GRAPH TRIGGERS IN VIATRA2
Graph transformations         Graph transformations• Graph rewriting based on rules       h     ii b d          l• Driven ...
Incremental graph pattern matching Incremental graph pattern matching• Graph transformations require pattern   matchingg• ...
Core idea: use RETE1 nets• RETE network                                                             INPUT    – node: (part...
Updates• N d d h  Needed when the model space changes                 h     d l       h• VIATRA notification mechanism (EM...
Event‐driven live transformations    Event driven live transformations  An idea: represent events as model elements.2• A i...
Formalism@trigger(sensitivity=“rise”, priority=“1”, mode=“always”)@ i        (     i i i     “ i ”    i i        “ ”      ...
Execution                   Transaction1            Commit        Transaction2   Matching set delta monitor               ...
APPLICATIONS & FUTURE WORK
Case studies                           Case studies• Domain‐specific visual languages (ViatraDSM)     – Incremental, on‐th...
Performance4                                                  Object-Relational Mapping                          100000   ...
Future work                  Future work• I  Improving performance        i      f  – Parallel (multi‐core) execution  – R...
Conclusion• Live transformation engine for incremental graph    i        f     i      i f i             l     h  transform...
Upcoming SlideShare
Loading in …5
×

Live model transformations driven by incremental pattern matching

2,081 views

Published on

Conference presentation at ICMT 2008.

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

Live model transformations driven by incremental pattern matching

  1. 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 iB d t University of  T h l it f Technology and Economics dE i ICMT, July 2, 2008 ICMT J l 2 2008
  2. 2. Overview• I t d ti Introduction• Live transformations• The VIATRA implementation• Future work• Summary
  3. 3. INTRODUCTION
  4. 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. 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. 6. Incremental updatesIncremental updates modification S1 S2 S3 Sn t tR tR tR merge T1 T2 T3 Tn
  7. 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. 8. Live transformations Live transformations 0 modification S1 S2 S3 Sn t tL transformation  tL tL context update T1 T2 T3 Tn0Hearnden‐Lawley‐Raymond. Incremental Model Transformation for the Evolution of Model‐driven Systems. MODELS 2006.
  9. 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. 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. 11. GRAPH TRIGGERS IN VIATRA2
  12. 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. 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. 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. 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. 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. 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. 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. 19. APPLICATIONS & FUTURE WORK
  20. 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 & simulation33Ráth‐Vágó‐Varró. Design‐time simulation of domain‐specific models by incremental pattern matching. Accepted for VL/HCC 2008.
  21. 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. 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. 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.

×