EMF-­‐INCQUERY	                      Incremental	  evalua7on	  of	  model	  queries	  over	  EMF	  models    	            ...
MOTIVATION	  
Hi	  Jane,	  what	  do	  you	  do	  at	  work?	  Jane	                                                                    ...
Hi	  Jane,	  you	  look	  so	  sad.	  What	  is	  wrong?	    It	  takes	  me	  hours	  to	  write	  a	          Why	  do...
Hi	  Jane,	  you	  look	  so	  sad.	  What	  is	  wrong?	    It	  takes	  me	  hours	  to	  write	  a	     query	  of	  a...
Hi	  Jane,	  you	  look	  so	  sad.	  What	  is	  wrong?	    It	  takes	  me	  hours	  to	  write	  a	     query	  of	  a...
STATE	  OF	  THE	  ART	  
Problem	  1:	  Expressiveness	    EMF	  Query	  (declara7ve)	     o Low	  expressiveness	     o Limited	  navigability	  ...
Problem	  2:	  Incrementality	    Goal:	  Incremental	  evala7on	  of	  model	  queries	      o Incremental	  maintenance...
Problem	  3:	  Performance	    Na7ve	  EMF	  queries	  (Java	  program	  code):	  	     Lack	  of	  	      o Reverse	  na...
Contribu7ons	    Expressive	  declara7ve	  query	  language	  by	  graph	  paeerns	    Incremental	  cache	  of	  matche...
Contribu7ons	    Expressive	  declara7ve	  query	  language	  by	  graph	  paeerns	      o Capture	  local	  +	  global	 ...
QUERY	  LANGUAGE	  
Contribu7ons	    Expressive	  declara7ve	  query	  language	  by	  graph	  paeerns	      o Capture	  local	  +	  global	 ...
Paeern	  defini7on	                                                                Graphical	  nota7on	                    ...
Graph	  paeerns	  (VTCL)	                                                                                                 ...
Posi7ve	  and	  Nega7ve	  paeerns	  (VTCL)	  topLevelClass(A)	                                                            ...
Recursive	  paeerns	  (VTCL)	                                                                              pattern descend...
Origins	  of	  the	  idea	    Model	  transforma7ons	  by	  VIATRA2	      o  Transforma7on	  language	           •  Decla...
Applica7ons	  of	  VIATRA2	    “Stand-­‐alone”	  model	  transforma7ons	    Early	  model-­‐based	  analysis	  	     (DE...
INCREMENTAL	  PATTERN	  MATCHING	  
Contribu7ons	    Expressive	  declara7ve	  query	  language	  by	  graph	  paeerns	      o Capture	  local	  +	  global	 ...
Incremental	  graph	  paeern	  matching	    Goal:	  retrieve	  the	  match	  set	  quickly	    How?	  	  RETE	  network...
RETE	  net	    RETE	  network	                                               a b c           ISignal	  objects	      o  n...
RETE	  nets	                                                      a b c 	  Class	  objects	    RETE	  network	      o  no...
EMF-­‐INCQUERY	  
Overview	    What	  is	  EMF-­‐INCQuery?	      o Query	  language	  +	  incremental	  paeern	  matcher	  +	        develo...
Architectural	  overview	                                                    RETE	  Core	  Paeern/Query	             EMF	 ...
EMF-­‐INCQUERY	  TOOLING	  
EMF-­‐INCQUERY	  Tooling	    Genera7ve	  approach	     o compile	  queries	  into	  	         •  RETE	  network	  builder...
Tooling	  architecture	   Declara7ve	  Queries	     3   Generated	  Query	       in	  VIATRA2	                Wrappers	   ...
Development	  workflow	                                     Semi-­‐automated	  for	                                      ty...
Impor7ng	  EMF	  domains	    Automated	  by	  the	  EMF2VIATRA	  plug-­‐in	  	     (by	  OptXware	  Ltd.)	    Generic	  ...
ECore	  models	  in	  VIATRA2	    Ecore	                                                      VIATRA2	      o EClass	   ...
Developing	  and	  tes7ng	  queries	    Supported	  by	  the	  VIATRA2	  framework	    LPG-­‐based	  parser	     o Recov...
Genera7ng	  INCQuery	  code	    Just	  a	  few	  clicks	  necessary	    Generated	  components:	  INCQuery	  run7me	    ...
EMF-­‐INCQUERY	  RUNTIME	  
Facili7es	  Generic	  Query	  API	   Generic	  Change	  API	  Generated	  Query	         Generated	  Change	        API	  ...
Generated	  Query	  API	    Basic	  queries	      o Uses	  tuples	  (object	  arrays)	  corresponding	  to	  paeern	  par...
Query	  DTOs	                                                 // B is a sibling class of A  Data	  Transfer	  Objects	   ...
Query	  DTOs	                                                 // B is a sibling class of A  Data	  Transfer	  Objects	   ...
Change	  API	    Track	  changes	  in	  the	  match	  set	  of	  paeerns	  (new/lost)	    Delta	  monitors	      o May	 ...
Integra7ng	  into	  EMF	  applica7ons	    Paeern	  matchers	  may	  be	  ini7alized	  for	     o Any	  EMF	  No7fier	     ...
Typical	  programming	  paeerns	  1.  Ini7alize	  EMF	  model	     o  Usually	  already	  done	  by	  your	  app	  	  2. ...
CASE	  STUDY	  
Case	  study:	  UML	  valida7on	    Goal:	  	     well-­‐formedness	  constraint	  valida7on	  over	  UML2	    Requireme...
Example	  UML	  well-­‐formedness	  constraint	    Diamonds	  are	  the	  girl’s	     best	  friend	      o But	  our	  s...
Formaliza7on	  pattern SuperType(Sub, Super) ={   Class(Sub);   Generalization.specific(GS, Gen, Sub);          Sub:	  Cla...
Formaliza7on	  pattern SuperType(Sub, Super) ={   Class(Sub);   Generalization.specific(GS, Gen, Sub);          Sub:	  Cla...
Formaliza7on	  pattern SuperType(Sub, Super) ={   Class(Sub);   Generalization.specific(GS, Gen, Sub);          Sub:	  Cla...
Formaliza7on	  pattern diamond(CA,C1,C2,C3) ={   Class(CA); Class(C1); Class(C2); Class(C3);   find SuperType(C1,CA);   fi...
Formaliza7on	  pattern diamond(CA,C1,C2,C3) ={   Class(CA); Class(C1); Class(C2); Class(C3);   find SuperType(C1,CA);   fi...
Formaliza7on	  pattern diamond(CA,C1,C2,C3) ={   Class(CA); Class(C1); Class(C2); Class(C3);   find SuperType(C1,CA);   fi...
Formaliza7on	  pattern diamond(CA,C1,C2,C3) ={   Class(CA); Class(C1); Class(C2); Class(C3);   find SuperType(C1,CA);   fi...
Formaliza7on	     Problem:	  transi7vity	  needs	  to	      be	  taken	  into	  account	                       Common	   ...
Paeern	  development	  in	  VIATRA2	    Import	  the	  UML	  metamodel	    Import	  UML	  instance	  models	  	    VTCL...
Genera7ng	  INCQuery	  wrappers	    Create	  INCQuery	  project	    INCQuery	  project	  set-­‐up	  and	  customiza7on	 ...
Integra7on	  into	  Papyrus	  UML	    Papyrus	  uses	  org.eclipse.uml2	  models	  internally	       o  Managed	  in	  a	...
Integra7on	  into	  Papyrus	  UML	    We	  implemented	  manually:	      o  Custom	  light-­‐weight	  valida7on	  extensi...
On-­‐the-­‐fly	  incremental	  valida7on	  by	  delta	  monitors	  idm.getReteEngine().getAfterUpdateCallbacks().add(new Ru...
On-­‐the-­‐fly	  incremental	  valida7on	  by	  delta	  monitors	  private Collection<InheritanceDiamondDTO> processNewMatc...
DEMO	   How	  does	  it	  work?	  
PERFORMANCE	  
Challenges	    Performance	  evalua7ons	  are	  hard	      o Fair?	      o Reliable?	      o Reproducible?	      o Can	  ...
What	  is	  measured?	    Sample	  models	  were	  generated	       o  matches	  are	  scarce	  rela7ve	  to	  overall	  ...
INCQuery	  Results	    Hardware:	  normal	  desktop	  PC	  (Core2,	  4GB	  RAM)	    Model	  sizes	  up	  to	  1.5m	  ele...
Ini7aliza7on	  7me	                       • Includes	  7me	  for	                        	                       first	  va...
Recomputa7on	  7me	         Recomputa7on	        7me	  is	  uniformly	            near	  zero	        (independent	  of	  ...
Performance	  overview	  
Assessment	  of	  the	  benchmark	    On-­‐the-­‐fly	  valida7on	  is	  only	  one	  scenario	      o Early	  model-­‐base...
CONCLUSION	  
Contribu7ons	    Expressive	  declara7ve	  query	  language	  by	  graph	  paeerns	      o Capture	  local	  +	  global	 ...
Pointers	    Details	  on	  availability	  soon	  to	  follow	      o hep://viatra.inf.mit.bme.hu/incquery	    Will	  be...
Upcoming SlideShare
Loading in …5
×

EMF-IncQuery: Incremental evaluation of model queries over EMF models

730 views

Published on

Tutorial at MODELS 2010.

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

No Downloads
Views
Total views
730
On SlideShare
0
From Embeds
0
Number of Embeds
14
Actions
Shares
0
Downloads
3
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

EMF-IncQuery: Incremental evaluation of model queries over EMF models

  1. 1. EMF-­‐INCQUERY   Incremental  evalua7on  of  model  queries  over  EMF  models   Gábor  Bergmann,  Ákos  Horváth,     István  Ráth,  Dániel  Varró   András  Balogh,  Zoltán  Balogh,     András  Ökrös,  Zoltán  Ujhelyi   Budapest  University  of  Technology  and  Economics   OptXware  Research  and  Development  LLC  Budapest  University  of  Technology  and  Economics  Department  of  Measurement  and  Informa<on  Systems  
  2. 2. MOTIVATION  
  3. 3. Hi  Jane,  what  do  you  do  at  work?  Jane   Detect!   Gen   Report!   Query  /   View  Boss   Constraint  
  4. 4. Hi  Jane,  you  look  so  sad.  What  is  wrong?    It  takes  me  hours  to  write  a     Why  don’t  you  use  a  declara7ve   query  of  an  EMF  model   query  language  (like  OCL)?   Jane   Boss  
  5. 5. Hi  Jane,  you  look  so  sad.  What  is  wrong?    It  takes  me  hours  to  write  a   query  of  an  EMF  model    I  need  to  re-­‐run  the  checks     Why  don’t  you  try   from  scratch  every  7me   something  incremental?   Jane   Boss  
  6. 6. Hi  Jane,  you  look  so  sad.  What  is  wrong?    It  takes  me  hours  to  write  a   query  of  an  EMF  model    I  need  to  re-­‐run  the  checks   from  scratch  every  7me    I  go  to  have  lunch  while   running  well-­‐formedness   Oh,  Jane,  you  must  eat  a  lot!     checks  on  large  UML  models   Jane   Boss  
  7. 7. STATE  OF  THE  ART  
  8. 8. Problem  1:  Expressiveness    EMF  Query  (declara7ve)   o Low  expressiveness   o Limited  navigability   •  no  „cycles”   ?  OCL  (declara7ve)   o Verbose     o Lack  of  reusability  support   o Local  constraints  of     a  model  element   o Poor  handling  of  recursion   Challenging  to  use  
  9. 9. Problem  2:  Incrementality    Goal:  Incremental  evala7on  of  model  queries   o Incremental  maintenance  of  result  set   o Avoid  unnecessary  re-­‐computa7on    Related  work:     o Constraint  evalua7on  (by  A.  Egyed)   •  Arbitrary  constraint  descrip7on   –  Can  be  a  boeleneck  for  complex  constraints   –  Always  local  to  a  model  element   •  Listen  to  model  no7fica7ons     •  Calculate  which  constraints  need  to  be  reevaluated   o No  other  related  technology  directly  over  EMF   o Research  MT  tools:  with  varying  degrees  of  support  
  10. 10. Problem  3:  Performance    Na7ve  EMF  queries  (Java  program  code):     Lack  of     o Reverse  naviga7on  along  references   o Enumera7on  of  all  instances  by  type   o Smart  Caching    Scalability  of  (academic)  MT  tools   o Queries  over  >100K  model  elements  (several  proofs):     FUJABA,  VIATRA2  (Java),  GrGEN,  VMTS  (.Net),  Egyed’s   tools  
  11. 11. Contribu7ons    Expressive  declara7ve  query  language  by  graph  paeerns    Incremental  cache  of  matches  (materialized  view)    High  performance  for  large  models  
  12. 12. Contribu7ons    Expressive  declara7ve  query  language  by  graph  paeerns   o Capture  local  +  global  queries   o Composi7onality  +  Reusabilility     o „Arbitrary”  Recursion,  Nega7on    Incremental  cache  of  matches  (materialized  view)   o Cheap  maintenance  of  cache  (only  memory  overhead)   o No7fy  about  relevant  changes   o Enable  reac7ons  to  complex  structural  events    High  performance  for  large  models   o Linear  overhead  for  loading     o Instant  response  for  queries   o >  1  million  model  elements  (on  desktop  PC)  
  13. 13. QUERY  LANGUAGE  
  14. 14. Contribu7ons    Expressive  declara7ve  query  language  by  graph  paeerns   o Capture  local  +  global  queries   o Composi7onality  +  Reusabilility     o „Arbitrary”  Recursion,  Nega7on    Incremental  cache  of  matches  (materialized  view)    High  performance  for  large  models  
  15. 15. Paeern  defini7on   Graphical  nota7on   implements  paeern  siblingClass(C1,C2)   UI  Model   superClass   S:  Class   S   GComp   Cmd   Iface   S1:superClass   S2:superClass   Class   C1   Bueon   ImageBueon   C2   C1:  Class   C2:  Class   matching   s1:implement     Graph  Paeern:     o  Structural  condi7on  that  have  to  be   GComp:Class   Cmd:Iface   fulfilled  by  a  part  of  the  model  space   s2:included     Graph  paeern  matching:   s1:superClass   i2:implement:  Iface   o  A  model  (i.e.  part  of  the  model  space)   Bueon:Class   ImageBueon:Class   can  sa7sfy  a  graph  paeern,     o  if  the  paeern  can  be  matched  to  a   subgraph  of  the  model     Instance  Model  
  16. 16. Graph  paeerns  (VTCL)   // B is a sibling class of AsiblingClass(A,B)   pattern siblingClass(A, B) = { P:  Class   Class(A); s1:superClass   s2:superClass   Class.superClass(S1, A, P); Class(P); A:  Class   B:  Class   Class.superClass(S2, B, P); Class(B); } // S is locally substitutable by AlocallySubs  (A,  S,  X)   pattern localSubs(A, S, X) = { Class(A); X:  Iface   Iface(X); Class.implements(I1, A, X); I1:implements   I2:implements   Class(S); Class.implements(I2, S, X); A:  Class   S:Class   } or { OR   Class(A); X:  Class   OR  paeern   Class(X); Class.superClass(P1, X, X); s1:superClass   s2:  superClass   Class(S); A:  Class   S:Class   Class.superClass(P2, S, X); }
  17. 17. Posi7ve  and  Nega7ve  paeerns  (VTCL)  topLevelClass(A)   pattern topLevelClass(A) = { Nega7ve   Class(A); A:  Class   paeern   neg find subClass(A); wSuperClass(X)   } X pattern wSuperClass(X) = { neg find X:  Class   A:  Class   Class(X); wSuperClass s1:superClass   Class.superClass(S1, X, A); Class(A);suspiciousClass(X)   } pattern suspiciousClass(X) = { X:  Class   A:  Class   Class(X); Posi7ve   S1:superClass   find topLevelClass(X); IA:isAbstract   paeern   Class.superClass(S1, A, X); X find B:  Boolean   Class(A);topLevelClass Class.isAbstract(IA, A, B); Boolean(B);check  (B  ==  false);   check (value(B) == "false"); }
  18. 18. Recursive  paeerns  (VTCL)   pattern descendant(X, D) = {paeern  descendant(X,D)   Class(X); X:  Class   Class.superClass(S, Ch, X); S:superClass   OR  paeern   Class(Ch); Recursive   paeern   find descendant(Ch, D) Ch:  Class   D:  Class   Class(D); } or { Class(X); X D Class.superClass(S, D, X); find descendant Class(D); OR   } S:superClass   D:  Class   X:  Class  
  19. 19. Origins  of  the  idea    Model  transforma7ons  by  VIATRA2   o  Transforma7on  language   •  Declara7ve  paeerns  for  model  queries   •  Graph  transforma7on  rules  for  elementary  mapping  specifica7ons     •  ASM  rules  for  control  structure   o  Matching  strategy   •  Local  search-­‐based  (op7mized  search  plans)   •  Incremental  paNern  matching  (based  on  RETE)   •  Hybrid  paeern  matching  (adap7ve  combina7on  of  INC  and  LS)    Development  team   o Developed  by  BUTE  and  OptXware  Ltd.   o 9  developers    More  info   o  hep://eclipse.org/gmt/VIATRA2   o  hep://wiki.eclipse.org/VIATRA2  
  20. 20. Applica7ons  of  VIATRA2    “Stand-­‐alone”  model  transforma7ons    Early  model-­‐based  analysis     (DECOS,  SecureChange)    Integrated  features  for  graphical  DSMLs   (ViatraDSM)    Model  execu7on/analysis  (stochas7c  GT)    (Development)  tool  integra7on     (DECOS,  SENSORIA,  MOGENTES)    Model  op7miza7on  /  constraint  solving  (DIANA)  
  21. 21. INCREMENTAL  PATTERN  MATCHING  
  22. 22. Contribu7ons    Expressive  declara7ve  query  language  by  graph  paeerns   o Capture  local  +  global  queries   o Composi7onality  +  Reusabilility     o „Arbitrary”  Recursion,  Nega7on    Incremental  cache  of  matches  (materialized  view)   o Cheap  maintenance  of  cache  (only  memory  overhead)   o No7fy  about  relevant  changes  (new  match  –  lost  match)   o Enable  reac7ons  to  complex  structural  events    High  performance  for  large  models  
  23. 23. Incremental  graph  paeern  matching    Goal:  retrieve  the  match  set  quickly    How?    RETE  network   o Store  (cache)  matches   o Incrementally  update  them  as  the  model  changes   •  Update  precisely    Experimental  results:  good,  if…   o There  is  enough  memory   o Transac7onal  model  manipula7on  
  24. 24. RETE  net    RETE  network   a b c ISignal  objects   o  node:  (par7al)  matches     of  a  (sub)paeern   EMF  RISignal.systemSignal  edges   esourceSet   x z w SystemSignal  objects   EMF  no<fica<on  m  echanism   o  edge:  update   propaga7on   Transparent:  user  modifica7on,   INPUT   INPUT   INPUT   model  imports,  results  of  a   SS  :  SystemSignal   S  :  ISignal   S  :  ISignal   w Input  nodes   a transforma7on,  external   R1:systemSignal   modifica7on,  …     x z b c   RETE  is  always  updated!   SS  :  SystemSignal   JOIN   ANTI-­‐JOIN   Intermediate   S  :  ISignal   Produc7on   S  :  ISignal    Demonstration   R1:systemSignal   nodes   x R1:systemSignal   o  input:  AUTOSAR  model   o  paeern:  ISignal  check   x SS  :  SystemSignal   z node   NEG   SS  :  SystemSignal   o  change:  delete  systemSignal  edge     CC_ISignal(S)   a c
  25. 25. RETE  nets   a b c  Class  objects    RETE  network   o  node:  (par7al)  matches     In-­‐memory  model TypedElement.type  edges   of  a  (sub)paeern   No<fica<on  pdate     o  edge:  u (EMF  RTypedElement  objects   x z w esourceSet)   propaga7on   Transparent:  user  modifica7on,   INPUT   INPUT   INPUT  PATTERN   results  of  lass   model  imports,   C:  C a   TE:  TypedElement   C  :  Class   C  :  Class   w Input  nodes   aUnusedClass(C)   external   transforma7on,    T  :  type   modifica7on,  …     x z UnusedClass(C)   b c   RETE  is  always  updated!   TE:  TypedElement   T:  type   NEG   A  class  to  which  no  type  reference  points   •  ssocia7on   A Experimental  results:   JOIN   •  roperty   P TE:  TypedElement   ANTI-­‐JOIN   good,  if…   Intermediate   C  :  Class   Parameter   •  Produc7on   C  :  Class    Demonstration  nough   o  There  is  e  T  :  type   •  ariable   V nodes    T  :  type   o  input:  UML  model   memory   o  paeern:  UnusedClass   o  Transac7onal  model   x TE:  TypedElement   z x node   NEG   TE:  TypedElement   o  change:  delete/retarget  type  reference   manipula7on   UnusedClass(C)   a c
  26. 26. EMF-­‐INCQUERY  
  27. 27. Overview    What  is  EMF-­‐INCQuery?   o Query  language  +  incremental  paeern  matcher  +   development  tools  for  EMF  models   •  Works  with  any  (pure)  EMF  applica7on   •  Reusability  by  paeern  composi7on   •  Arbitrary  recursion,  nega7on   •  Generic  and  parameterized  model  queries   •  Bidirec7onal  navigability   •  Immediate  access  to  all  instances  of  a  type   •  Complex  change  detec7on    Benefits   o Fully  declara7ve  +  Scalable  performance  
  28. 28. Architectural  overview   RETE  Core  Paeern/Query   EMF  INC  PM   VIATRA2  INC  PM   spec   Core   Generated  PM  and  RETE   EMF  App   builder  
  29. 29. EMF-­‐INCQUERY  TOOLING  
  30. 30. EMF-­‐INCQUERY  Tooling    Genera7ve  approach   o compile  queries  into     •  RETE  network  builders   •  Query  interface  wrappers   o end-­‐to-­‐end  solu7on:  generates  Eclipse  plug-­‐in  projects    Relies  on  the  VIATRA2  environment   o query  development   o debugging    
  31. 31. Tooling  architecture   Declara7ve  Queries   3 Generated  Query   in  VIATRA2   Wrappers   4 EMF  App   2 VIATRA2     EMF  Model  model  representa7on   1 Development  7me   Run7me  
  32. 32. Development  workflow   Semi-­‐automated  for   typical  scenarios,  Import  EMF    some  manual  coding   Integrate  into  EMF  domain  into   applica7on   VIATRA2   Automated   Develop  and  test   Generate  INCQuery   queries  over   code   VIATRA2   Supported  by   the  VIATRA2   IDE  
  33. 33. Impor7ng  EMF  domains    Automated  by  the  EMF2VIATRA  plug-­‐in     (by  OptXware  Ltd.)    Generic  support  to  process     o ECore  metamodels  and     o EMF-­‐based  instance  models     o within  the  VIATRA2  model  space    Available  as  an  independent  open  source  add-­‐on   to  VIATRA2  
  34. 34. ECore  models  in  VIATRA2    Ecore     VIATRA2   o EClass   o En7ty  (Node)   o EReference   o Rela7on  (Edge)   o EAeribute   o Node+Edge   Car:  EClass   Car   parts:  EReference   parts   weight   +weight:  EInt   Part:  EClass   Integer   Part   MyCar:  Car   :parts   MyCar:  Car   :weight   MyWheel:   weight  =  1500   Part   parts  =  [MyWheel:Part]   :  Integer   value  =    1500  
  35. 35. Developing  and  tes7ng  queries    Supported  by  the  VIATRA2  framework    LPG-­‐based  parser   o Recovery  parsing,  error  highligh7ng   o Light-­‐weight  sta7c  analysis  for  paeerns     (type  and  metamodel  conformance)    Development  features   o Paeern  graph  visualiza7on   o Paeern  match  set  visualiza7on   o Execute  paeerns  (in  transforma7ons)  
  36. 36. Genera7ng  INCQuery  code    Just  a  few  clicks  necessary    Generated  components:  INCQuery  run7me   o Eclipse  plugin   •  Depends  only  on  EMF  and  the  INCQuery  core   •  No  VIATRA2  dependency!     o Private  code:  paeern  builders   •  Parameterize  the  RETE  core  and  the  generic  EMF  PM  library   o Public  API:  Paeern  matcher  access  layer   •  Query  interfaces   •  Data  Transfer  Objects  (DTOs)   •  Used  to  integrate  to  EMF  applica7ons    
  37. 37. EMF-­‐INCQUERY  RUNTIME  
  38. 38. Facili7es  Generic  Query  API   Generic  Change  API  Generated  Query   Generated  Change   API   API  
  39. 39. Generated  Query  API    Basic  queries   o Uses  tuples  (object  arrays)  corresponding  to  paeern  parameters   o Object[] getOneMatch() o Collection<Object[]> getAllMatches()  Parameterized  queries   o getOneMatch(Object X, Object Y, …) o getAllMatches(Object X, Object Y, …) o Null  input  values  =  unbound  input  variables   Based  on  paeern   signature  
  40. 40. Query  DTOs   // B is a sibling class of A  Data  Transfer  Objects   pattern siblingClass(C1, C2) = generated  for     { /* contents */ paeern  signatures   }  DTO  query  methods   o  SiblingClassDTO getOneMatch() o  SiblingClassDTO getOneMatch (Object C1, Object C2) public class SiblingClassDTO o  Collection<SiblingClassDTO> { getAllMatches() Object C1; o  Collection<SiblingClassDTO> Object C2; getAllMatches(Object C1, Object C2) }  C1,  C2:  EObjects  or     datatype  instances     (String,  Boolean,  …)  
  41. 41. Query  DTOs   // B is a sibling class of A  Data  Transfer  Objects   pattern siblingClass(C1, C2) = generated  for     { /* contents */ paeern  signatures   }  DTO  query  methods   o  SiblingClassDTO getOneMatch() o  SiblingClassDTO getOneMatch (UMLClass C1, UMLClass C2) public class SiblingClassDTO o  Collection<SiblingClassDTO> { getAllMatches() UMLClass C1; o  Collection<SiblingClassDTO> UMLClass C2; getAllMatches(UMLClass C1, } UMLClass C2) Ongoing  work:  use    C1,  C2:  EObjects  or     domain-­‐specific   datatype  instances     types  in  generated   (String,  Boolean,  …)   code  
  42. 42. Change  API    Track  changes  in  the  match  set  of  paeerns  (new/lost)    Delta  monitors   o May  be  ini7alized  at  any  7me   o DeltaMonitor.matchFoundEvents / DeltaMonitor.matchLostEvents •  Queues  of  matches  (tuples/DTOs)  that  have  appeared/disappeared  since   ini7aliza7on    Typical  usage   o Listen  to  model  manipula7on  (transac7ons)   o A{er  transac7on  commits:   •  Evaluate  delta  monitor  contents  and  process  changes   •  Remove  processed    tuples/DTOs  from  .matchFound/LostEvents  
  43. 43. Integra7ng  into  EMF  applica7ons    Paeern  matchers  may  be  ini7alized  for   o Any  EMF  No7fier   •  e.g.  Resources,  ResourceSets   o Transac7onalEdi7ngDomains    Ini7aliza7on   o Possible  at  any  7me   o Involves  a  single  exhaus7ve  model  traversal   (independent  of  the  number  of  paeerns,  paeern   contents  etc.)  
  44. 44. Typical  programming  paeerns  1.  Ini7alize  EMF  model   o  Usually  already  done  by  your  app    2.  Ini7alize  incremental  PM  whenever  necessary  3.  Use  the  incremental  PM  for  queries   o  Model  updates  will  be  processed  transparently,  with   minimal  performance  overhead   o  Delta  monitors  can  be  used  to  track  complex  changes  4.  Dispose  the  PM  when  not  needed  anymore   o  +  Frees  memory   o  -­‐  Re-­‐traversal  will  be  necessary  
  45. 45. CASE  STUDY  
  46. 46. Case  study:  UML  valida7on    Goal:     well-­‐formedness  constraint  valida7on  over  UML2    Requirements   o Live  /  on-­‐the-­‐fly:     instantaneous  feedback  as  the  user  is  edi7ng   o Incremental:  fast  for  large  models    Ingredients     o Papyrus  UML   o VIATRA2  R3.2   o EMF-­‐INCQuery  
  47. 47. Example  UML  well-­‐formedness  constraint    Diamonds  are  the  girl’s   best  friend   o But  our  system  architect’s   worst  enemy      The  “diamond”  is  a  (local)   an7-­‐paeern   o Mul7ple  inheritance  (and   polymorphism)  can  be   problema7c  in  some   programming  languages    Goal:  detect     diamond  structures  in   UML  class  diagrams    
  48. 48. Formaliza7on  pattern SuperType(Sub, Super) ={ Class(Sub); Generalization.specific(GS, Gen, Sub); Sub:  Class   Generalization(Gen); Generalization.general(GG, Gen, Super); Class(Super); :  specific  } Gen:  Generaliza7on   :  general   Super:  Class  
  49. 49. Formaliza7on  pattern SuperType(Sub, Super) ={ Class(Sub); Generalization.specific(GS, Gen, Sub); Sub:  Class   Generalization(Gen); Generalization.general(GG, Gen, Super); Class(Super); :  specific  } Gen:  Generaliza7on   :  general   Super:  Class  
  50. 50. Formaliza7on  pattern SuperType(Sub, Super) ={ Class(Sub); Generalization.specific(GS, Gen, Sub); Sub:  Class   Generalization(Gen); Generalization.general(GG, Gen, Super); Class(Super); :  specific  } Gen:  Generaliza7on   :  general   Super:  Class  
  51. 51. Formaliza7on  pattern diamond(CA,C1,C2,C3) ={ Class(CA); Class(C1); Class(C2); Class(C3); find SuperType(C1,CA); find SuperType(C2,CA); find SuperType(C3,C1); Common   find SuperType(C3,C2); Ancestor:  Class   neg find SuperType(C1,C2); neg find SuperType(C2,C1);}pattern SuperType(Sub, Super) = C1:  Class   C2:  Class  { Class(Sub); Generalization.specific(GS, Gen, Sub); Generalization(Gen); Generalization.general(GG, Gen, Super); Class(Super); C3:  Class  }
  52. 52. Formaliza7on  pattern diamond(CA,C1,C2,C3) ={ Class(CA); Class(C1); Class(C2); Class(C3); find SuperType(C1,CA); find SuperType(C2,CA); find SuperType(C3,C1); Common   find SuperType(C3,C2); Ancestor:  Class   neg find SuperType(C1,C2); neg find SuperType(C2,C1);}pattern SuperType(Sub, Super) = C1:  Class   C2:  Class  { Class(Sub); Generalization.specific(GS, Gen, Sub); Generalization(Gen); Generalization.general(GG, Gen, Super); Class(Super); C3:  Class  }
  53. 53. Formaliza7on  pattern diamond(CA,C1,C2,C3) ={ Class(CA); Class(C1); Class(C2); Class(C3); find SuperType(C1,CA); find SuperType(C2,CA); find SuperType(C3,C1); Common   find SuperType(C3,C2); Ancestor:  Class   neg find SuperType(C1,C2); neg find SuperType(C2,C1);}pattern SuperType(Sub, Super) = C1:  Class   C2:  Class  { Class(Sub); Generalization.specific(GS, Gen, Sub); Generalization(Gen); Generalization.general(GG, Gen, Super); Class(Super); C3:  Class  }
  54. 54. Formaliza7on  pattern diamond(CA,C1,C2,C3) ={ Class(CA); Class(C1); Class(C2); Class(C3); find SuperType(C1,CA); find SuperType(C2,CA); find SuperType(C3,C1); Common   find SuperType(C3,C2); Ancestor:  Class   neg find SuperType(C1,C2); neg find SuperType(C2,C1);}pattern SuperType(Sub, Super) = C1:  Class   C2:  Class  { Class(Sub); Generalization.specific(GS, Gen, Sub); Generalization(Gen); Generalization.general(GG, Gen, Super); Class(Super); C3:  Class  }
  55. 55. Formaliza7on     Problem:  transi7vity  needs  to   be  taken  into  account   Common     Solu7on:  recursion   Ancestor:  Class  pattern transitiveSuperType(Sub, Super) ={ find SuperType(Sub,Super); } OR { find transitiveSuperType(Sub, Middle); find SuperType(Middle,Super); C2’:  Class  }pattern diamond(CA,C1,C2,C3) ={ Class(CA); Class(C1); Class(C2); Class(C3); C1:  Class   find transitiveSuperType(C1,CA); C2:  Class   find transitiveSuperType(C2,CA); find transitiveSuperType(C3,C1); find transitiveSuperType(C3,C2); neg find transitiveSuperType(C1,C2); neg find transitiveSuperType(C2,C1); C3:  Class  }
  56. 56. Paeern  development  in  VIATRA2    Import  the  UML  metamodel    Import  UML  instance  models      VTCL  development  environment   o Create  and  debug  paeerns   o Visualize  paeerns  and  paeern  matches   o Test  queries/paeerns  in  transforma7ons  
  57. 57. Genera7ng  INCQuery  wrappers    Create  INCQuery  project    INCQuery  project  set-­‐up  and  customiza7on    Genera7ng  code  
  58. 58. Integra7on  into  Papyrus  UML    Papyrus  uses  org.eclipse.uml2  models  internally   o  Managed  in  a  standard  ResourceSet   o  No  Transac7onalEdi7ngDomain  support    Valida7on  is  facilitated  using  EMF-­‐Valida7on   o  Inflexible   Not  suitable  for   o  Manages  live  valida7on  by  a  different  paradigm   our  purposes   o  Constraints  rely  on  manually  coded  model  traversal  
  59. 59. Integra7on  into  Papyrus  UML    We  implemented  manually:   o  Custom  light-­‐weight  valida7on  extension  (200  LOC)   •  Based  on  Eclipse  resource  markers   •  Generically  reusable  for  any  EMF  model   o  UI  integra7on  (150  LOC)   •  Contributed  menu  item   •  Relevant  part:  15  LOC     •  Generically  reusable   o  Constraint-­‐specific  code   •  Graph  paeerns  (18  LOC  in  VTCL)   •  Adapter  class  (~15  LOC  in  Java)   –  extends  the  light-­‐weight  valida7on  feedback  framework    All  the  rest  is  automa7cally  generated.  
  60. 60. On-­‐the-­‐fly  incremental  valida7on  by  delta  monitors  idm.getReteEngine().getAfterUpdateCallbacks().add(new Runnable() {!@Override!public void run() {! Simple  mechanism  // after each model update, check the delta monitor! to  register  call-­‐// FIXME should be: after each complete transaction, check the delta monitor! backs  that  execute   a{er  all  updates  dm.matchFoundEvents.removeAll( processNewMatches(dm.matchFoundEvents, outline, f.getFile()) );! have  been   propagated  dm.matchLostEvents.removeAll( processLostMatches(dm.matchLostEvents, outline, f.getFile()) );!}!});   Core  technique  of   processing  changes  
  61. 61. On-­‐the-­‐fly  incremental  valida7on  by  delta  monitors  private Collection<InheritanceDiamondDTO> processNewMatches (Collection<InheritanceDiamondDTO> dtos, IFile f) throws CoreException {!Vector<InheritanceDiamondDTO> processed = new Vector<InheritanceDiamondDTO>();!for (InheritanceDiamondDTO diamond : dtos) {! Process  paeern  " Vector<EObject> affectedElements = new Vector<EObject>();! signature  DTOs  " affectedElements.add((EObject)diamond.getA());!" affectedElements.add((EObject)diamond.getB());!" affectedElements.add((EObject)diamond.getC());!" affectedElements.add((EObject)diamond.getD());!" ValidationUtil.markProblem(f, affectedElements, ! ValidationProblemKind.DIAMOND);!" processed.add(diamond);! Make  sure  to   Use  light-­‐weight  }! remove  a   valida7on  facility  return processed;! processed   to  create  error  }   change  from  the   marker   queue  
  62. 62. DEMO   How  does  it  work?  
  63. 63. PERFORMANCE  
  64. 64. Challenges    Performance  evalua7ons  are  hard   o Fair?   o Reliable?   o Reproducible?   o Can  the  results  be  generalized?    Benchmark  example:     on-­‐the-­‐fly  constraint  valida7on  over  AUTOSAR  models   o Conference  presenta7on  tomorrow,  11-­‐12.30,  Hall  B   o Mo7va7on:  the  Embedded  Architect  Tool  of  OptXware  Ltd.   o AUTOSAR  models  can  be  very  large  (>>1m  elements)  
  65. 65. What  is  measured?    Sample  models  were  generated   o  matches  are  scarce  rela7ve  to  overall  model  size    On-­‐the-­‐fly  valida7on  is  modeled  as  follows:   1.  Compute  ini7al  valida7on  results   2.  Apply  randomly  distributed,  small  changes   3.  Re-­‐compute  valida7on  results    Measured:  execu7on  7mes  of   o  Ini7aliza7on  (model  load  +  RETE  construc7on)   o  Model  manipula7on  opera7ons  (negligible)   o  Valida7on  result  (re)computa7on    Compared  technologies   o  MDT-­‐OCL   o  Plain  Java  code  that  an  average  developer  would  write  
  66. 66. INCQuery  Results    Hardware:  normal  desktop  PC  (Core2,  4GB  RAM)    Model  sizes  up  to  1.5m  elements    Ini7aliza7on  7mes  (resource  loading  +  first  valida7on)   o  <1  sec  for  model  sizes  below  50000  elements   o  Up  to  40  seconds  for  the  largest  model  (grows  linearly  with  the  model  size)    Recomputa7on  7mes   o  Within  error  of  measurement  (=0),  independent  of  model  size   o  Retrieval  of  matches  AND  complex  changes  is  instantaneous    Memory  overhead   o  <50  MB  for  model  sizes  below  50000  elements   o  Up  to  1GB  for  the  largest  model  (grows  linearly  with  model  size)    How  does  it  compare  to  na7ve  code  /  OCL?   o See  the  conference  talk  tomorrow    
  67. 67. Ini7aliza7on  7me   • Includes  7me  for     first  valida7on   • Linear  func7on  of     model  size,  orders   of  magnitude  faster  
  68. 68. Recomputa7on  7me   Recomputa7on   7me  is  uniformly   near  zero   (independent  of   model  size)  
  69. 69. Performance  overview  
  70. 70. Assessment  of  the  benchmark    On-­‐the-­‐fly  valida7on  is  only  one  scenario   o Early  model-­‐based  analysis     o Language  engineering  in  graphical  DSMLs   o Model  execu7on/analysis  (stochas7c  GT)   o Tool  integra7on     o Model  op7miza7on  /  constraint  solving    Example  AUTOSAR  queries   o Do  not  make  use  of  advanced  features  such  as   parameterized  queries  or  complex  structural   constraints  (recursion)  
  71. 71. CONCLUSION  
  72. 72. Contribu7ons    Expressive  declara7ve  query  language  by  graph  paeerns   o Capture  local  +  global  queries   o Composi7onality  +  Reusabilility     o „Arbitrary”  Recursion,  Nega7on    Incremental  cache  of  matches  (materialized  view)   o Cheap  maintenance  of  cache  (only  memory  overhead)   o No7fy  about  relevant  changes   o Enable  reac7ons  to  complex  structural  events    High  performance  for  large  models   o Linear  overhead  for  loading     o Instant  response  for  queries   o >  1  million  model  elements  (on  desktop  PC)  
  73. 73. Pointers    Details  on  availability  soon  to  follow   o hep://viatra.inf.mit.bme.hu/incquery    Will  be  integrated  into  OptXware’s  tools   o hep://optxware.com/en/embedded   o hep://optxware.com/en/modeling-­‐infrastructure    Thank  you  for  your  kind  aeen7on.  

×