Applicaons	  of	  incremental	  pa1ern	                     matching	  in	  model	  transformaons                         ...
Overview Introducon    o VIATRA2    o Incremental	  graph	  pa1ern	  matching Part	  I:	  The	  impact	  on	  performanc...
About	  me h1p://mit.bme.hu/~rath	   I	  am   o a	  soRware	  engineer	  graduated	  in	  2006   o a	  PhD	  candidate	 ...
INTRODUCTIONGraph	  Transformaons	  from	  the	  VIATRA2	  perspecve…                                                     ...
VIATRA2	  is… A	  graph	  transformaon	  tool    o h1p://eclipse.org/gmt/VIATRA2    o h1p://wiki.eclipse.org/VIATRA2    o...
Applicaons	  of	  VIATRA2 “Stand-­‐alone”	  model	  transformaons Early	  analysis	  (DECOS,	  SecureChange) Integrated...
7                   Metamodeling                            1                       tokens            Place               ...
7                          Metamodeling                                                                            Class  ...
8                 Graph	  Transformaon   LHS                                                        RHS             a1:ina...
8                 Graph	  Transformaon   LHS                                                        RHS             a1:ina...
8                  Graph	  Transformaon    LHS                                                             RHS            ...
Incremental	  model	  transformaons Key	  usage	  scenarios	  for	  MT:     o Mapping	  between	  languages     o Intra-­...
Towards	  incrementality How	  to	  achieve	  incrementality?   o Incremental	  updates:	  avoid	  re-­‐generaon.      • ...
Towards	  incrementality How	  to	  achieve	  incrementality?   o Incremental	  updates:	  avoid	  re-­‐generaon.      • ...
INCREMENTAL	  GRAPH	  PATTERN	          MATCHING                                      11
Incremental	  graph	  pa1ern	  matching Graph	  transforma;ons	  require	  paQern	  matching   o Most	  expensive	  phase...
Operaonal	  overview                            XForm	  pa1ern	  matching        interpreter           model	  manipulaon ...
Core	  idea:	  use	  RETE	  nets RETE	  network                                                                        IN...
Core	  idea:	  use	  RETE	  nets RETE	  network                                                          Model	  space   ...
Core	  idea:	  use	  RETE	  nets RETE	  network                                                                        IN...
Core	  idea:	  use	  RETE	  nets RETE	  network                                                                          ...
Core	  idea:	  use	  RETE	  nets RETE	  network                                                                          ...
Core	  idea:	  use	  RETE	  nets RETE	  network                                                                          ...
Core	  idea:	  use	  RETE	  nets RETE	  network                                                                          ...
Core	  idea:	  use	  RETE	  nets RETE	  network                                                                          ...
RETE	  network	  construcon Key:	  paQern	  decomposi;on   o PaQern	  =	  set	  of	  constraints	  (defined	  over	  paQer...
Key	  RETE	  components JOIN	  node                                                    INPUT                             ...
Supporng	  a	  rich	  pa1ern	  language PaQern	  calls   o Simply	  connect	  the	  produc;on	  nodes   o  PaQern	  recu...
Updates Needed	  when	  the	  model	  space	  changes VIATRA	  no;fica;on	  mechanism	  (EMF	  is	  also	  possible)   o ...
PART	  I:	  IMPACT	  ON	  PERFORMANCE                                            19
20       Benchmarking	  in	  graph	  transforma;on Specificaon	  examples	  for	  GT   o Goal:	  assessing	  expressivenes...
Inial	  benchmarking:	  summary Benchmarking	  scenarios	  focused	  on	     o “tradional”	  MT	  use	  cases	  such	  as...
Further	  improvements Parallelism   o Update	  the	  RETE	  network	  in	  parallel	  with	  the	       transformaon   o...
Parallelism:	  lessons	  learned Can	  be	  good	  AND	  bad	  for	  performance Cannot	  be	  easily	  automated VERY	...
Hybrid	  PM:	  lessons	  learned Paper	  for	  a	  special	  issue	  in	  STTT’09:	  Experimental	    assessment	  of	  c...
EMF-­‐INCQUERYIncremental	  pa1ern	  matching	  beyond	  VIATRA2                                                         25
Movaon VIATRA2	  has	  lacked	  generic	  EMF	  support    o Even	  though	  UML2	  and	  some	  other	  EMF-­‐based	  la...
Goals EMF	  lacks	  a	  fast	  query	  engine    o MDT-­‐OCL,	  EMF	  Query	  do	  not	  scale	  well Goal	  1:	  port	 ...
EMF-­‐IncQuery:	  overview At	  runme   o Incremental	  pa1ern	  matching	  engine	  for	  EMF	  models   o Uses	  the	  ...
Architecture               29
Evaluaon (To	  be)	  Presented	  at	  MODELS2010   o Gábor	  Bergmann,	  Ákos	  Horváth,	  István	  Ráth,	  Dániel	      ...
Performance              31
Summary Several	  orders	  of	  magnitude	  faster	  than	  the	  state-­‐of-­‐the-­‐  art    o Constraint	  re-­‐evaluao...
Future	  research	  targets Keyword	  #1:	  scalability  oModel	  size  oQuery/transforma;on	  complexity  oReal	  ;me	  ...
Scalability	  challenges VIATRA2,	  EMF,	  …	  hit	  the	  limit	  at	  a	  few	  (1-­‐5)	  million	  model	    elements	...
Teamwork	  (and	  other)	  challenges Painful	  problems	  in	  DSML	  pracce    o Metamodel	  evoluon    o Model	  compa...
Our	  vision               Model	  spaceCollabora     ve	    client-­‐      Paron	       Paron	     Paron	       Nave     ...
Our	  vision               Model	  spaceCollabora     ve	    client-­‐      Paron	       Paron	     Paron	            Nave...
Our	  vision               Model	  space                                Out-­‐of-­‐memory	  Collabora                     ...
Our	  vision                         Model	  space                                Out-­‐of-­‐memory	  Collabora           ...
Our	  vision                         Model	  space                    Out-­‐of-­‐memory	  Collabora                       ...
Our	  vision                         Model	  space                    Out-­‐of-­‐memory	  Collabora                       ...
PART	  II:	  BEYOND	  PERFORMANCE                                       37
What	  really	  is	  INC? Graph	  pa1erns	  ~	  complex	  constraint	  sets   o Matching	  set:	  overlay	  of	  “valid”	...
What	  really	  is	  INC? Graph	  pa1erns	  ~	  complex	  constraint	  sets   o Matching	  set:	  overlay	  of	  “valid”	...
Idea Use	  the	  historical	  overlay	  to    o Easily	  compute	  non-­‐trivial	  change	  informaon	  (beyond	        e...
Event-­‐driven	  live	  transformaons Represent	  events	  as	  changes	  in	  the	  matching	  set	  of	  a	    paQern. ...
Change-­‐driven	  transformaons Generalizaon	  of	  the	  live	  transformaon	  approach New	  formalism	  supports	  mo...
Constraint	  sasfacon	  over	  models Movaon    o Very	  pragmac	  problem	  area:	  constraint	  evaluaon,	  “quick	  fix...
CSP(M) Described	  by	  	  (M0,C,G,L)   o M0	  ini+al	  model	  (typed	  graph)   o C	  set	  of	  global	  constraints	 ...
Implementaon	  with	  VIATRA2 Incremental	  constraint	  evaluaon	  by	  incremental	    pa1ern	  matching   o Cached	  m...
Extensions	  of	  CSP(M) Flexible	  CSP   o Strong-­‐weak	  constraints   o Quality	  metrics Dynamic	  CSP   o Add-­‐re...
Current	  state	  of	  CSP(M) “Pure”	  and	  “Flexible”	  CSP(M)   o Execuon	  mes	  significantly	  faster	  than	  KORAT...
Stochas;c	  simula;on	  by	  graph	  transforma;on Joint	  work	  with	  Reiko	  Heckel’s	  group	  (University	  of	    ...
Idea Conceptually	  similar	  to	  the	    CSP	  engine   o Simulaon	  rule:	  precondion	       +	  transformaon   o Ass...
Applicaons VoIP	  P2P	  network	  behavioral	  simulaon	  (Skype) Other	  simulaon	  scenarios   o Social	  networks   o...
FUTURE         50
Research	  topics	  overview Transformaon	  engineering   o   Change-­‐driven	  transformaons   o   Stac	  program	  chec...
Upcoming SlideShare
Loading in …5
×

Applications of incremental pattern matching in model transformations

868 views

Published on

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

Published in: Technology, Economy & Finance
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
868
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Applications of incremental pattern matching in model transformations

  1. 1. Applicaons  of  incremental  pa1ern   matching  in  model  transformaons István  Ráth  (rath@mit.bme.hu) Budapest  University  of  Technology  and  EconomicsBudapest  University  of  Technology  and  EconomicsDepartment  of  Measurement  and  Informa<on  Systems 1
  2. 2. Overview Introducon 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  transformaons o Constraint  sasfacon  solving  over  models  –  CSP(M) o Model  simulaon  by  stochasc  graph  transformaons   Future  research  direcons 2
  3. 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. 4. INTRODUCTIONGraph  Transformaons  from  the  VIATRA2  perspecve… 4
  5. 5. VIATRA2  is… A  graph  transformaon  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  parcipants  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)   organizaons  world-­‐wide 5
  6. 6. Applicaons  of  VIATRA2 “Stand-­‐alone”  model  transformaons Early  analysis  (DECOS,  SecureChange) Integrated  features  for  graphical  DSMLs   (ViatraDSM) Model  execuon/analysis  (stochasc  GT) (Development)  tool  integraon  (DECOS,  SENSORIA,   MOGENTES) Model  opmizaon  /  constraint  solving  (DIANA) 6
  7. 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:outarctkn3:tokens to1:Token t2:Transition 7
  8. 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:outarctkn3:tokens to1:Token t2:Transition 7
  9. 9. 8 Graph  Transformaon LHS RHS a1:inarc a2:outarc a1:inarc a2:outarc Place Tran. Place Place Tran. Plan ttn1:tokens tkn2:tokens Token TokenPhases of GT matching – Pattern Matching phase – Updating phase: delete+ create 8
  10. 10. 8 Graph  Transformaon LHS RHS a1:inarc a2:outarc a1:inarc a2:outarc Place Tran. Place Place Tran. Plan ttn1:tokens tkn2:tokens Token Token matchingPhases of GT matching – Pattern Matching phase – Updating phase: delete+ create 8
  11. 11. 8 Graph  Transformaon LHS RHS a1:inarc a2:outarc a1:inarc a2:outarc Place Tran. Place Place Tran. Plan ttn1:tokens tkn2:tokens Token Token matching updatingPhases of GT matching – Pattern Matching phase – Updating phase: delete+ createPattern Matching is the most critical issue from performance viewpoint 8
  12. 12. Incremental  model  transformaons 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. 13. Towards  incrementality How  to  achieve  incrementality? o Incremental  updates:  avoid  re-­‐generaon. • Don’t  recreate  what  is  already  there. •  Use  reference  (correspondence)  models. o Incremental  execu+on:  avoid  re-­‐computaon. • Don’t  recalculate  what  was  already  computed. • How? 10
  14. 14. Towards  incrementality How  to  achieve  incrementality? o Incremental  updates:  avoid  re-­‐generaon. • Don’t  recreate  what  is  already  there. •  Use  reference  (correspondence)  models. o Incremental  execu+on:  avoid  re-­‐computaon. • Don’t  recalculate  what  was  already  computed. • How? 10
  15. 15. INCREMENTAL  GRAPH  PATTERN   MATCHING 11
  16. 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. 17. Operaonal  overview XForm  pa1ern  matching interpreter model  manipulaon Incremental VIATRA    pa1ern event   noficaon Model  space matcher updates 13
  18. 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 :  Transion 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. 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 :  Transion 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. 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 :  Transion 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. 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 :  Transion 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. 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 :  Transion 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. 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 :  Transion 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. 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 :  Transion 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. 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 :  Transion 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. 26. RETE  network  construcon 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. 27. Key  RETE  components JOIN  node INPUT INPUT INPUT o ~relaonal  algebra:   natural  join JOIN MINUS-­‐JOIN JOIN o Negave  existence   (NACs) PRODUCTION sourcePlace 16
  28. 28. Supporng  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. 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. 30. PART  I:  IMPACT  ON  PERFORMANCE 19
  31. 31. 20 Benchmarking  in  graph  transforma;on Specificaon  examples  for  GT o Goal:  assessing  expressiveness o UML-­‐to-­‐XMI,  object-­‐relaonal  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. 32. Inial  benchmarking:  summary Benchmarking  scenarios  focused  on   o “tradional”  MT  use  cases  such  as  model   synchronizaon o Addional  use  cases  where  INC  expected  to  be  very   good  (e.g.  model  execuon,  constraint  evaluaon) Predictable  near-­‐linear  growth o As  long  as  there  is  enough  memory o Certain  problem  classes:  constant  execuon  me   Some  benchmark  example  descripons,  specificaons,   and  measurement  results  available  at: o hPp://wiki.eclipse.org/VIATRA2/Benchmarks 21
  33. 33. Further  improvements Parallelism o Update  the  RETE  network  in  parallel  with  the   transformaon o Support  parallel  transformaon  execuon o Paper  at  GT-­‐VMT’09:  Parallelizaon  of  Graph   Transformaon 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  transformaons  by   combining  pa1ern  matching  strategies 22
  34. 34. Parallelism:  lessons  learned Can  be  good  AND  bad  for  performance Cannot  be  easily  automated VERY  problem  specific! Ongoing  research:  true  parallel  GT  execuon o “High”  level  specificaon  language • Supports  locking  and  synchronizaon 23
  35. 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  execuon  me   retains   complexity  class  characteriscs  24
  36. 36. EMF-­‐INCQUERYIncremental  pa1ern  matching  beyond  VIATRA2 25
  37. 37. Movaon 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   representaon o N-­‐level  metamodeling  (VPM)  vs.  MOF-­‐style  (EMF) o Graph  structures  (VPM)  vs.  A1ributed  nodes  (EMF) o Dynamic  typing  (VPM)  vs.  Stac  (generave)  types  (EMF) o Mul-­‐domain  modelspace  (VPM)  vs.  domain-­‐specific  resources   (EMF) 26
  38. 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,  effecve  model  queries o Easy-­‐to-­‐use  declarave  API  (graph  pa1erns) o Support  for  on-­‐the-­‐fly  constraint  evaluaon  and  other   scenarios Goal  2:  generic  EMF  support  for  VIATRA2  R3.x o Reflecve  and  generave  model  export-­‐import   27
  39. 39. EMF-­‐IncQuery:  overview At  runme o Incremental  pa1ern  matching  engine  for  EMF  models o Uses  the  EMF  Noficaon  API  for  updates o Works  with  any  transacon-­‐based  EMF  applicaon • Minor  modificaon  necessary o Supports  generic  as  well  as  parameterized  model  queries o Supports  VIATRA2’s  rich  declarave  pa1ern  language  (recursion,   composion,  a1ribute  constraints…) o No  VIATRA2  dependency As  tooling o Generave:  compiles  queries  into  RETE  networks  (vs.  VIATRA2’s   dynamic  approach) o Relies  on  VIATRA2  for  query  development  and  debugging   28
  40. 40. Architecture 29
  41. 41. Evaluaon (To  be)  Presented  at  MODELS2010 o Gábor  Bergmann,  Ákos  Horváth,  István  Ráth,  Dániel   Varró:  Incremental  Evaluaon  of  Model  Queries  over   EMF  Models o Case  study:  AUTOSAR  on-­‐the-­‐fly  constraint  evaluaon • Simple  and  complex  constraints o Compared  to: • MDT-­‐OCL • EMF  Query • Ad-­‐hoc  Java  implementaon 30
  42. 42. Performance 31
  43. 43. Summary Several  orders  of  magnitude  faster  than  the  state-­‐of-­‐the-­‐ art o Constraint  re-­‐evaluaon:  nearly  constant  execuon  mes Price  of  performance:  memory  consumpon o Grows  linearly  with  the  model  size  (even  for  complex   constraints) o To  be  addressed  in  future  work Addional  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. 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. 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 Transformaon  complexity  is  growing o As  MT  gains  more  industrial  exposure o Problem  areas:  re-­‐use  (libraries),  design  pa1erns,  execuon   infrastructure,  specificaon  complexity  … 34
  46. 46. Teamwork  (and  other)  challenges Painful  problems  in  DSML  pracce o Metamodel  evoluon o Model  comparison,  versioning,  conflict  resoluon,   merge o Concurrent  teamwork,  collaborave  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”  soluon  yet 35
  47. 47. Our  vision Model  spaceCollabora ve   client-­‐ Paron   Paron   Paron   Nave Nave server   (EMF) (UML) (RDF) persistence Nave persistence persistence access High  performance   INC transformaon  engine Language  adapters VIATRA ATL QVT 36
  48. 48. Our  vision Model  spaceCollabora ve   client-­‐ Paron   Paron   Paron   Nave Nave server   (EMF) (UML) (RDF) persistence Nave persistence persistence access No  need  for   model  export-­‐ import High  performance   INC transformaon  engine Language  adapters VIATRA ATL QVT 36
  49. 49. Our  vision Model  space Out-­‐of-­‐memory  Collabora model  storage ve   client-­‐ Paron   Paron   Paron   Nave Nave server   (EMF) (UML) (RDF) persistence Nave persistence persistence access No  need  for   model  export-­‐ import High  performance   INC transformaon  engine Language  adapters VIATRA ATL QVT 36
  50. 50. Our  vision Model  space Out-­‐of-­‐memory  Collabora model  storage ve   client-­‐ Paron   Paron   Paron   Nave Nave server   (EMF) (UML) (RDF) persistence Nave persistence persistence access No  need  for   model  export-­‐ import High  performance   INC transformaon  engine Acts  as  a   “common   Language  adapters VIATRA ATL QVT runme” 36
  51. 51. Our  vision Model  space Out-­‐of-­‐memory  Collabora model  storage ve   client-­‐ Paron   Paron   Paron   Nave Nave server   (EMF) (UML) (RDF) persistence Nave persistence persistence access No  need  for   Supports   model  export-­‐ distributed   import models  and   High  performance   versioning INC transformaon  engine Acts  as  a   “common   Language  adapters VIATRA ATL QVT runme” 36
  52. 52. Our  vision Model  space Out-­‐of-­‐memory  Collabora model  storage ve   client-­‐ Paron   Paron   Paron   Nave Nave server   (EMF) (UML) (RDF) persistence Nave persistence persistence access No  need  for   Supports   model  export-­‐ distributed   import models  and   High  performance   versioning INC transformaon  engine Adapve  IPM   Acts  as  a   engine  (lower   “common   Language  adapters memory   runme” VIATRA ATL QVT footprint) 36
  53. 53. PART  II:  BEYOND  PERFORMANCE 37
  54. 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. 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. 56. Idea Use  the  historical  overlay  to o Easily  compute  non-­‐trivial  change  informaon  (beyond   elementary  changes) • Detect  high-­‐level  “events” • Detect  (the  net  effect  of)  complex  change  sequences o Assign  acons  to  these  changes • Event-­‐Condion-­‐Acon  formalism  in  rule-­‐based  systems •   event-­‐driven  transformaons o Or,  easily  track  the  validity  set  of  constraints  as  the  model  is   evolving •   constraint  sasfacon  solving o Or,  easily  track  enabledness  condions  for  simulaon  rules •   stochasc  model  simulaon 39
  57. 57. Event-­‐driven  live  transformaons 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. 58. Change-­‐driven  transformaons Generalizaon  of  the  live  transformaon  approach New  formalism  supports  more  precise  change  queries o To  disnguish  between  various  execuon  trajectories  that  result   in  the  same  net  change o A  more  complete  adaptaon  of  the  ECA  approach  to  graph   transformaons Applicaon  scenarios o Incremental  model  synchronizaon  for  non-­‐materialized  models   (paper  at  MODELS2009:  Change-­‐driven  transformaons) o Back-­‐annotaon  of  simulaon  traces  (paper  at  SEFM2010) 41
  59. 59. Constraint  sasfacon  over  models Movaon o Very  pragmac  problem  area:  constraint  evaluaon,  “quick  fix”   computaon,  design  or  configuraon-­‐space  exploraon  etc. o CLP(FD)  limited:  only  finite  problems  can  be  formulated • Problemac:  object  birth-­‐and-­‐death o CLP(FD)  difficult  to  use GT-­‐based  approaches o Easier-­‐to-­‐use  formalism o Infinite  (dynamic)  problems o “Tradional”  problem:  scalability   Our  aim:  combine  ease-­‐of-­‐use  and  flexibility  with   performance   42
  60. 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  sasfies  all  global  constraints   and  goals. • One  model • All  model • Opmal  model 43
  61. 61. Implementaon  with  VIATRA2 Incremental  constraint  evaluaon  by  incremental   pa1ern  matching o Cached  matchings o Incrementally  updated Simple  state  space  representaon Typed  graph  comparison o DSMDiFF Backtracking o Transacons  of  atomic  manipulaon  operaons 44
  62. 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. 63. Current  state  of  CSP(M) “Pure”  and  “Flexible”  CSP(M) o Execuon  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  potenal  for  future  research 46
  64. 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:  Stochasc   simulaon  of  graph  transformaon  systems o GT-­‐VMT2010:  P.  Torrini,  R.  Heckel,  I.  Ráth,  G.  Bergmann:   Stochasc  graph  transformaon  with  regions o ASMTA2010:  A.  Khan,  P.  Torrini,  R.  Heckel  and  I.  Ráth:   Model-­‐based  stochasc  simulaon  of  P2P  VoIP  using   graph  transformaon 47
  65. 65. Idea Conceptually  similar  to  the   CSP  engine o Simulaon  rule:  precondion   +  transformaon o Assign  probability   distribuons  to  simulaon   rules o Execute  as-­‐long-­‐as-­‐possible o Observe  system  state   changes 48
  66. 66. Applicaons VoIP  P2P  network  behavioral  simulaon  (Skype) Other  simulaon  scenarios o Social  networks o Traffic  networks o Crystal  growth Evaluaon o +:  Scales  well  (comparable  to  dedicated  simulators) o +:  GT  is  an  easier-­‐to-­‐use  specificaon  formalism 49
  67. 67. FUTURE 50
  68. 68. Research  topics  overview Transformaon  engineering o Change-­‐driven  transformaons o Stac  program  checking  for  transformaons o Re-­‐factoring  and  composion  (transformaon  chains) o Model  transformaon  by  example o Semiautomac  back-­‐annotaon  for  dynamic  languages o From  OCL  to  graph  pa1erns  and  back New  applicaons o Stochasc  simulaon o CSP(M) Scalability o Very  large  models o Collaborave  model  repositories o Opmizaon  of  the  IPM  engine 51

×