73
Budapest University of Technology and Economics Department of Measurement and Informa<on Systems Budapest University of Technology and Economics OptXware Research and Development LLC EMFINCQUERY 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

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

Embed Size (px)

DESCRIPTION

Tutorial at MODELS 2010.

Citation preview

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

Budapest  University  of  Technology  and  Economics  Department  of  Measurement  and  Informa<on  Systems  

Budapest  University  of  Technology  and  Economics  OptXware  Research  and  Development  LLC  

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  

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

MOTIVATION  

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

Hi  Jane,  what  do  you  do  at  work?  

Jane  

Boss  

Detect!  

Report!  Query  /  View  

Constraint  

Gen  

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

Hi  Jane,  you  look  so  sad.  What  is  wrong?    It  takes  me  hours  to  write  a  

query  of  an  EMF  model    Why  don’t  you  use  a  declara7ve  

query  language  (like  OCL)?  

Jane   Boss  

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

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  

 Why  don’t  you  try  something  incremental?  

Jane   Boss  

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

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  checks  on  large  UML  models  

Oh,  Jane,  you  must  eat  a  lot!    

Jane   Boss  

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

STATE  OF  THE  ART  

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

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  

?

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

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  

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

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  

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

Contribu7ons    Expressive  declara7ve  query  language  by  graph  paeerns  

  Incremental  cache  of  matches  (materialized  view)  

  High  performance  for  large  models  

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

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)  

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

QUERY  LANGUAGE  

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

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  

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

implements  

superClass  

Class  

Iface  

UI  Model  

Bueon   ImageBueon  

GComp   Cmd  

C1   C2  

S  

Bueon:Class   ImageBueon:Class  

GComp:Class   Cmd:Iface  

s1:superClass  

s1:implement  

s2:included  

i2:implement:  Iface  

C1:  Class   C2:  Class  

S:  Class  

S1:superClass   S2:superClass  

paeern  siblingClass(C1,C2)  

Instance  Model  

Graphical  nota7on  Paeern  defini7on  

matching    Graph  Paeern:    

o  Structural  condi7on  that  have  to  be  fulfilled  by  a  part  of  the  model  space  

  Graph  paeern  matching:  o  A  model  (i.e.  part  of  the  model  space)  

can  sa7sfy  a  graph  paeern,    

o  if  the  paeern  can  be  matched  to  a  subgraph  of  the  model    

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

Graph  paeerns  (VTCL)  // B is a sibling class of A pattern siblingClass(A, B) = { Class(A); Class.superClass(S1, A, P); Class(P); Class.superClass(S2, B, P); Class(B); }

OR  paeern  

A:  Class   B:  Class  

P:  Class  

s1:superClass   s2:superClass  

siblingClass(A,B)  

A:  Class   S:Class  

X:  Iface  

I1:implements   I2:implements  

locallySubs  (A,  S,  X)  

OR  

A:  Class   S:Class  

X:  Class  

s1:superClass   s2:  superClass  

// S is locally substitutable by A pattern localSubs(A, S, X) = { Class(A); Iface(X); Class.implements(I1, A, X); Class(S); Class.implements(I2, S, X); } or { Class(A); Class(X); Class.superClass(P1, X, X); Class(S); Class.superClass(P2, S, X); }

OR  paeern  

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

Posi7ve  and  Nega7ve  paeerns  (VTCL)  pattern topLevelClass(A) = { Class(A); neg find subClass(A); } pattern wSuperClass(X) = { Class(X); Class.superClass(S1, X, A); Class(A); } pattern suspiciousClass(X) = { Class(X);

find topLevelClass(X); Class.superClass(S1, A, X); Class(A); Class.isAbstract(IA, A, B); Boolean(B);

check (value(B) == "false"); }

Nega7ve  paeern  A:  Class  

topLevelClass(A)  

neg find wSuperClass

X X:  Class   A:  Class  

s1:superClass  

wSuperClass(X)  

X:  Class   A:  Class  S1:superClass  

suspiciousClass(X)  

find topLevelClass

X B:  Boolean  

IA:isAbstract  

check  (B  ==  false);  

Posi7ve  paeern  

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

Recursive  paeerns  (VTCL)  

pattern descendant(X, D) = { Class(X); Class.superClass(S, Ch, X); Class(Ch); find descendant(Ch, D) Class(D); } or { Class(X); Class.superClass(S, D, X); Class(D); }

OR  paeern  

Ch:  Class   D:  Class  

X:  Class  

S:superClass  

paeern  descendant(X,D)  

OR  

D:  Class   X:  Class  

S:superClass  

Recursive  paeern  

find descendant X D

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

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  

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

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)  

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

INCREMENTAL  PATTERN  MATCHING  

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

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  

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

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  

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

RETE  net  

INPUT  

R1:systemSignal  

S  :  ISignal  

SS  :  SystemSignal  

INPUT  SS  :  SystemSignal  

INPUT  S  :  ISignal  

JOIN  S  :  ISignal  

SS  :  SystemSignal  

R1:systemSignal  

ANTI-­‐JOIN  

NEG  

R1:systemSignal  

S  :  ISignal  

SS  :  SystemSignal  

CC_ISignal(S)  

  RETE  network  o  node:  (par7al)  matches    

of  a  (sub)paeern  o  edge:  update    

propaga7on  

  Demonstration  o  input:  AUTOSAR  model  o  paeern:  ISignal  check  o  change:  delete  systemSignal  edge    

a b c

x z w

ISignal  objects  

SystemSignal  objects  

ISignal.systemSignal  edges  

x z w a b c

x z

c

x

a

Input  nodes  

Intermediate  nodes  

EMF  ResourceSet  

Produc7on  node  

EMF  no<fica<on  mechanism  

Transparent:  user  modifica7on,  model  imports,  results  of  a  transforma7on,  external  modifica7on,  …      RETE  is  always  updated!  

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

RETE  nets  

INPUT  

 T  :  type  

C  :  Class  

TE:  TypedElement  

INPUT  TE:  TypedElement  

INPUT  C  :  Class  

JOIN  C  :  Class  

TE:  TypedElement  

 T  :  type  

ANTI-­‐JOIN  

NEG  

 T  :  type  

C  :  Class  

TE:  TypedElement  

UnusedClass(C)  

  RETE  network  o  node:  (par7al)  matches    

of  a  (sub)paeern  o  edge:  update    

propaga7on  

  Demonstration  o  input:  UML  model  o  paeern:  UnusedClass  o  change:  delete/retarget  type  reference  

a b c

x z w

 Class  objects  

TypedElement  objects  

TypedElement.type  edges  

x z w a b c

x z

c

x

a

Input  nodes  

Intermediate  nodes  

In-­‐memory  model(EMF  ResourceSet)  

Produc7on  node  

PATTERN  UnusedClass(C)  

C:  Class  

TE:  TypedElement  

NEG  

T:  type

 No<fica<on  

Transparent:  user  modifica7on,  model  imports,  results  of  a  transforma7on,  external  modifica7on,  …      RETE  is  always  updated!  

UnusedClass(C)  A  class  to  which  no  type  reference  points  • Associa7on  • Property  • Parameter  • Variable  

Experimental  results:  good,  if…  o  There  is  enough  

memory  

o  Transac7onal  model  manipula7on  

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

EMF-­‐INCQUERY  

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

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  

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

Architectural  overview  

RETE  Core  

EMF  INC  PM  Core  

VIATRA2  INC  PM  

EMF  App  

Paeern/Query  spec  

Generated  PM  and  RETE  builder  

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

EMF-­‐INCQUERY  TOOLING  

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

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    

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

Tooling  architecture  

VIATRA2    model  representa7on  

Declara7ve  Queries  in  VIATRA2  

Generated  Query  Wrappers  

EMF  Model  1

2 4

3

EMF  App  

Development  7me   Run7me  

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

Development  workflow  

Import  EMF  domain  into  VIATRA2  

Develop  and  test  queries  over  VIATRA2  

Generate  INCQuery  code  

Integrate  into  EMF  applica7on  

Automated  Automated  

Supported  by  the  VIATRA2  

IDE  

Semi-­‐automated  for  typical  scenarios,  

 some  manual  coding  

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

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  

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

ECore  models  in  VIATRA2    Ecore  

o EClass  o EReference  o EAeribute  

  VIATRA2  o En7ty  (Node)  o Rela7on  (Edge)  o Node+Edge  

Car:  EClass  

Part:  EClass  +weight:  EInt  

parts:  EReference  

MyCar:  Car  

weight  =  1500  parts  =  [MyWheel:Part]  

MyCar:  Car  

MyWheel:  Part  

:parts  

:  Integer  value  =    1500  

:weight  

Car  

Part  

parts  

Integer  

weight  

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

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)  

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

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    

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

EMF-­‐INCQUERY  RUNTIME  

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

Facili7es  

Generic  Query  API  

Generated  Change  API  

Generated  Query  API  

Generic  Change  API  

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

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  

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

Query  DTOs    Data  Transfer  Objects  generated  for    paeern  signatures  

  DTO  query  methods  o  SiblingClassDTO getOneMatch() o  SiblingClassDTO getOneMatch

(Object C1, Object C2)

o  Collection<SiblingClassDTO> getAllMatches()

o  Collection<SiblingClassDTO> getAllMatches(Object C1, Object C2)

  C1,  C2:  EObjects  or    datatype  instances    (String,  Boolean,  …)  

public class SiblingClassDTO

{

Object C1; Object C2;

}

// B is a sibling class of A pattern siblingClass(C1, C2) = { /* contents */ }

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

Query  DTOs  

Ongoing  work:  use  domain-­‐specific  

types  in  generated  code  

public class SiblingClassDTO

{

UMLClass C1;

UMLClass C2; }

  Data  Transfer  Objects  generated  for    paeern  signatures  

  DTO  query  methods  o  SiblingClassDTO getOneMatch() o  SiblingClassDTO getOneMatch

(UMLClass C1, UMLClass C2)

o  Collection<SiblingClassDTO> getAllMatches()

o  Collection<SiblingClassDTO> getAllMatches(UMLClass C1, UMLClass C2)

  C1,  C2:  EObjects  or    datatype  instances    (String,  Boolean,  …)  

// B is a sibling class of A pattern siblingClass(C1, C2) = { /* contents */ }

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

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  

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

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.)  

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

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  

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

CASE  STUDY  

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

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  

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

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    

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

Formaliza7on  pattern SuperType(Sub, Super) = { Class(Sub); Generalization.specific(GS, Gen, Sub); Generalization(Gen); Generalization.general(GG, Gen, Super); Class(Super); }

Sub:  Class  

Super:  Class  

Gen:  Generaliza7on  

:  specific  

:  general  

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

Formaliza7on  pattern SuperType(Sub, Super) = { Class(Sub); Generalization.specific(GS, Gen, Sub); Generalization(Gen); Generalization.general(GG, Gen, Super); Class(Super); }

Sub:  Class  

Super:  Class  

Gen:  Generaliza7on  

:  specific  

:  general  

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

Formaliza7on  pattern SuperType(Sub, Super) = { Class(Sub); Generalization.specific(GS, Gen, Sub); Generalization(Gen); Generalization.general(GG, Gen, Super); Class(Super); }

Sub:  Class  

Super:  Class  

Gen:  Generaliza7on  

:  specific  

:  general  

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

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); find SuperType(C3,C2); neg find SuperType(C1,C2); neg find SuperType(C2,C1); }

pattern SuperType(Sub, Super) = { Class(Sub); Generalization.specific(GS, Gen, Sub); Generalization(Gen); Generalization.general(GG, Gen, Super); Class(Super); }

Common  Ancestor:  Class  

C1:  Class   C2:  Class  

C3:  Class  

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

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); find SuperType(C3,C2); neg find SuperType(C1,C2); neg find SuperType(C2,C1); }

pattern SuperType(Sub, Super) = { Class(Sub); Generalization.specific(GS, Gen, Sub); Generalization(Gen); Generalization.general(GG, Gen, Super); Class(Super); }

Common  Ancestor:  Class  

C1:  Class   C2:  Class  

C3:  Class  

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

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); find SuperType(C3,C2); neg find SuperType(C1,C2); neg find SuperType(C2,C1); }

pattern SuperType(Sub, Super) = { Class(Sub); Generalization.specific(GS, Gen, Sub); Generalization(Gen); Generalization.general(GG, Gen, Super); Class(Super); }

Common  Ancestor:  Class  

C1:  Class   C2:  Class  

C3:  Class  

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

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); find SuperType(C3,C2); neg find SuperType(C1,C2); neg find SuperType(C2,C1); }

pattern SuperType(Sub, Super) = { Class(Sub); Generalization.specific(GS, Gen, Sub); Generalization(Gen); Generalization.general(GG, Gen, Super); Class(Super); }

Common  Ancestor:  Class  

C1:  Class   C2:  Class  

C3:  Class  

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

Formaliza7on  

Common  Ancestor:  Class  

C1:  Class  C2:  Class  

C3:  Class  

  Problem:  transi7vity  needs  to  be  taken  into  account  

  Solu7on:  recursion  

C2’:  Class  

pattern transitiveSuperType(Sub, Super) = { find SuperType(Sub,Super); } OR { find transitiveSuperType(Sub, Middle); find SuperType(Middle,Super); } pattern diamond(CA,C1,C2,C3) = { Class(CA); Class(C1); Class(C2); Class(C3); find transitiveSuperType(C1,CA); find transitiveSuperType(C2,CA); find transitiveSuperType(C3,C1); find transitiveSuperType(C3,C2); neg find transitiveSuperType(C1,C2); neg find transitiveSuperType(C2,C1); }

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

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  

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

Genera7ng  INCQuery  wrappers  

 Create  INCQuery  project    INCQuery  project  set-­‐up  and  customiza7on  

 Genera7ng  code  

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

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  o Manages  live  valida7on  by  a  different  paradigm  

o  Constraints  rely  on  manually  coded  model  traversal  

Not  suitable  for  our  purposes  

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

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.  

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

On-­‐the-­‐fly  incremental  valida7on  by  delta  monitors  

idm.getReteEngine().getAfterUpdateCallbacks().add(new Runnable() { !

@Override !public void run() { !// after each model update, check the delta monitor !// FIXME should be: after each complete transaction, check the delta

monitor !

dm.matchFoundEvents.removeAll( processNewMatches(dm.matchFoundEvents, outline, f.getFile()) ); !

dm.matchLostEvents.removeAll( processLostMatches(dm.matchLostEvents, outline, f.getFile()) ); !

} !});  

Simple  mechanism  to  register  call-­‐

backs  that  execute  a{er  all  updates  

have  been  propagated  

Core  technique  of  processing  changes  

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

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) { !" Vector<EObject> affectedElements = new Vector<EObject>(); !" 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); !} !return processed; !}  

Process  paeern  signature  DTOs  

Use  light-­‐weight  valida7on  facility  to  create  error  

marker  

Make  sure  to  remove  a  processed  

change  from  the  queue  

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

DEMO   How  does  it  work?  

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

PERFORMANCE  

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

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)  

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

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  

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

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    

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

Ini7aliza7on  7me  

•   Includes  7me  for  first  valida7on  •   Linear  func7on  of  model  size,  orders  of  magnitude  faster  

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

Recomputa7on  7me  

Recomputa7on  7me  is  uniformly  

near  zero  (independent  of  model  size)  

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

Performance  overview  

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

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)  

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

CONCLUSION  

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

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)  

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

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.