A tutorial on EMF-IncQuery

1,615 views
1,483 views

Published on

Tutorial at EC-MFA 2011.

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

No Downloads
Views
Total views
1,615
On SlideShare
0
From Embeds
0
Number of Embeds
27
Actions
Shares
0
Downloads
16
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

A tutorial on EMF-IncQuery

  1. 1. A  TUTORIAL  ON  EMF-­‐INCQUERY Incremental  evalua;on  of  model  queries  over  EMF  models Gábor  Bergmann,  Ákos  Horváth,   Ábel  Hegedüs,  Zoltán  Ujhelyi,  Balázs  Polgár,   István  Ráth,  Dániel  Varró Budapest  University  of  Technology  and  Economics Fault  Tolerant  Systems  Research  GroupBudapest  University  of  Technology  and  EconomicsDepartment  of  Measurement  and  Informa<on  Systems
  2. 2. Contents§ Mo;va;on o Model  queries…? o State  of  the  art  of  EMF  model  queries o Goals§ Technology  overview§ Hands-­‐on  part  1 o Basics  (UML  model  sta;s;cs)§ Break§ Hands-­‐on  part  2 o Advanced  well-­‐formedness  valida;on  for  UML o Integra;on  with  Papyrus  UML§ Conclusion o Performance  benchmarks o Q&A§ Feel  free  to  ask  ques4ons  along  the  way!
  3. 3. Downloads§ h_p://viatra.inf.mit.bme.hu/incquery/events/ecmfa2011#Files§ What  you’ll  need o Eclipse  Helios  (Modeling) • Make  sure  to  allocate  enough  heap  by  passing  “-­‐Xmx1024m”  through  eclipse.ini o Op;onally:  Papyrus  UML h_p://www.eclipse.org/modeling/mdt/papyrus/updates/index.php   o Everything  from  the  update  site   h_p://viatra.inf.mit.bme.hu/update/ecmfa11/   o In  your  workspace: • Sample  IncQuery  project  h_p://viatra.inf.mit.bme.hu/downloads/demo/ ecmfa11/ecmfa-­‐incquery-­‐project.zip   • Sample  Papyrus  UML  models  h_p://viatra.inf.mit.bme.hu/downloads/demo/ ecmfa11/ecmfa-­‐umlsamples-­‐project.zip  
  4. 4. MOTIVATIONWhile  you’re  downloading  J
  5. 5. First  of  all…§ What  is  a  model  query? o A  piece  of  code  that  looks  for  certain  parts  of  the   model.§ “Mathema;cally” o Query  =  set  of  constraints  that  have  to  be  sa;sfied  by   (parts  of)  the  model. o Result  =  set  of  model  elements  (element   configura;ons)  that  sa;sfy  the  constraints  of  the   query.§ A  query  engine? o Supports  the  defini;on/execu;on  of  model  queries.
  6. 6. Hi  Jane,  what  do  you  do  at  work?Jane
  7. 7. Hi  Jane,  what  do  you  do  at  work?Jane
  8. 8. Hi  Jane,  what  do  you  do  at  work?JaneBoss
  9. 9. Hi  Jane,  what  do  you  do  at  work?Jane DetectBoss Constraint
  10. 10. Hi  Jane,  what  do  you  do  at  work?Jane Detect ReportBoss Constraint
  11. 11. Hi  Jane,  what  do  you  do  at  work?Jane Detect Report ViewBoss Constraint
  12. 12. Hi  Jane,  what  do  you  do  at  work?Jane Detect Gen Report ViewBoss Constraint
  13. 13. Model  queries§ Queries  are  at  the  heart  of  MDD. o Views o Reports o Generators o Validators o…§ Development  issues o Complex  queries  are  hard  to  write
  14. 14. Issues  with  query  development§ Hard  to  write?§ Your  op;ons o Java  (or  C/C++,  C#,  …) o Declara;ve  languages  (OCL,  EMF  Query  1-­‐2,  …) Impera;ve  query  languages Declara;ve  query  languages Expressive  power L  (you  write  lots  of  code) J (very  concise) Safety JJ (precise  control  over   JL what  happens  at  execu;on) (unintended  side-­‐effects) Learning  curve J (you  already  know  it) L (may  be  difficult  to  learn) Reusability J (standard  OO  prac;ces) LL (???) Performance LJ (considerable  manual   JL (depends  on  various   op;miza;on  necessary) factors)
  15. 15. Issues  with  query  execu;on§ Query  performance o =  Execu;on  ;me,  as  a  func;on  of • Query  complexity • Model  size  /  contents • Result  set  size§ Incrementality o Don’t  forget  previously  computed  results! o Models  changes  are  usually  small,  yet  up-­‐to-­‐date  query   results  are  needed  all  the  ;me. o Incremental  evalua;on  is  an  essen;al,  but  not  a  very   well  supported  feature.
  16. 16. Model  query  engine  wish  list§ Declara;ve  query  language o Easy  to  learn o Good  bindings  to  the  impera;ve  world  (Java) o Safe  yet  powerful o Reusable§ High  performance o Fast  execu;on  for  complex  queries  over  large  models o First-­‐class  support  for  incremental  execu;on§ Technology o Works  with  EMF  out-­‐of-­‐the-­‐box
  17. 17. STATE  OF  THE  ART
  18. 18. Problem  1:  Expressiveness§ EMF  Query  (declara;ve) o Low  expressiveness o Limited  navigability • no  „cycles”§ OCL  (declara;ve) o Verbose   o Lack  of  reusability  support o Local  constraints  of   a  model  element o Poor  handling  of  recursion àChallenging  to  use
  19. 19. Problem  2:  Incrementality§ Goal:  Incremental  evala;on  of  model  queries o Incremental  maintenance  of  result  set o Avoid  unnecessary  re-­‐computa;on§ Related  work:   o Constraint  evalua;on  (by  A.  Egyed) • Arbitrary  constraint  descrip;on – Can  be  a  bo_leneck  for  complex  constraints – Always  local  to  a  model  element • Listen  to  model  no;fica;ons   • Calculate  which  constraints  need  to  be  reevaluated o No  other  related  technology  directly  over  EMF o Research  MT  tools:  with  varying  degrees  of  support
  20. 20. Problem  3:  Performance§ Na;ve  EMF  queries  (Java  program  code):   Lack  of   o Reverse  naviga;on  along  references o Enumera;on  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
  21. 21. EMF-­‐IncQuery§ Expressive  declara;ve  query  language  by  graph  pa_erns§ Incremental  cache  of  matches  (materialized  view)§ High  performance  for  large  models
  22. 22. INCQUERY  TECHNOLOGY  OVERVIEW
  23. 23. Technology  Overview§ What  is  EMF-­‐INCQuery? o Query  language  +  incremental  pa_ern  matcher  +   development  tools  for  EMF  models • Works  with  any  (pure)  EMF  applica;on • Reusability  by  pa_ern  composi;on • Arbitrary  recursion,  nega;on • Generic  and  parameterized  model  queries • Bidirec;onal  navigability • Immediate  access  to  all  instances  of  a  type • Complex  change  detec;on§ Benefits o Fully  declara;ve  +  Scalable  performance
  24. 24. Contribu;ons§ Expressive  declara;ve  query  language  by  graph  pa_erns o Capture  local  +  global  queries o Composi;onality  +  Reusabilility   o „Arbitrary”  Recursion,  Nega;on§ Incremental  cache  of  matches  (materialized  view)§ High  performance  for  large  models
  25. 25. Origins  of  the  idea§ Model  transforma;ons  by  VIATRA2 o Transforma;on  language • Declara;ve  pa_erns  for  model  queries • Graph  transforma;on  rules  for  elementary  mapping  specifica;ons   • ASM  rules  for  control  structure o Matching  strategy • Local  search-­‐based  (op;mized  search  plans) • Incremental  pa@ern  matching  (based  on  RETE) • Hybrid  pa_ern  matching  (adap;ve  combina;on  of  INC  and  LS)§ Developed  by  BUTE  and  OptXware  Ltd.§ More  info o h_p://eclipse.org/gmt/VIATRA2 o h_p://wiki.eclipse.org/VIATRA2
  26. 26. ECore  models  as  graphs§ Ecore § VIATRA2 o EClass o En;ty  (Node) o EReference o Rela;on  (Edge) o EA_ribute o Node+Edge Car:  EClass Car parts:  EReference parts weight +weight:  EInt Part:  EClass Integer Part MyCar:  Car :parts MyCar:  Car :weight MyWheel:  Part weight  =  1500 parts  =  [MyWheel:Part] :  Integer value  =    1500
  27. 27. Pa_ern  defini;on Graphical  nota;on implementspa_ern  siblingClass(C1,C2) UI  Model superClass S:  Class S GComp Cmd IfaceS1:superClass S2:superClass Class C1 Bu_on ImageBu_on C2 C1:  Class C2:  Class matching s1:implement § Graph  Pa_ern:   o Structural  condi;on  that  have  to  be   GComp:Class Cmd:Iface fulfilled  by  a  part  of  the  model  space s2:included § Graph  pa_ern  matching: s1:superClass i2:implement:  Iface o A  model  (i.e.  part  of  the  model  space)  c Bu_on:Class ImageBu_on:Class sa;sfy  a  graph  pa_ern,   o if  the  pa_ern  can  be  matched  to  a   subgraph  of  the  model   Instance  Model
  28. 28. Graph  pa_erns  (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); A:  Class B:  Class Class(P); Class.superClass(S2, B, P); Class(B);
  29. 29. Graph  pa_erns  (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); A:  Class B:  Class Class(P); 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);I1:implements I2:implements Class.implements(I1, A, X); Class(S); A:  Class S:Class Class.implements(I2, S, X); OR } or { X:  Class OR  pa_ern Class(A); Class(X); s1:superClass s2:  superClass Class.superClass(P1, X, X); A:  Class S:Class Class(S);
  30. 30. Contribu;ons§ Expressive  declara;ve  query  language  by  graph  pa_erns o Capture  local  +  global  queries o Composi;onality  +  Reusabilility   o „Arbitrary”  Recursion,  Nega;on§ Incremental  cache  of  matches  (materialized  view) o Cheap  maintenance  of  cache  (only  memory  overhead) o No;fy  about  relevant  changes  (new  match  –  lost  match) o Enable  reac;ons  to  complex  structural  events§ High  performance  for  large  models
  31. 31. RETE  nets§ RETE  network o node:  (par;al)  matches   of  a  (sub)pa_ern o edge:  update   propaga;onPATTERN INPUT INPUT INPUT C:  Class TE:  TypedElement C  :  Class C  :  ClassUnusedClass(C)  T  :  type TE:  TypedElement NEG T:  type TE:  TypedElement JOIN ANTI-­‐JOIN C  :  Class C  :  Class  T  :  type  T  :  type§ Demonstra;on TE:  TypedElement o input:  UML  model TE:  TypedElement NEG o pa_ern:  UnusedClass UnusedClass(C) o change:  delete/retarget  type  reference
  32. 32. RETE  nets§ RETE  network o node:  (par;al)  matches   of  a  (sub)pa_ern o edge:  update   propaga;onPATTERN INPUT INPUT INPUT C:  Class TE:  TypedElement C  :  Class C  :  ClassUnusedClass(C)  T  :  type UnusedClass(C) TE:  TypedElement NEG A  class  to  which  no  type  reference  points T:  type •Associa;on TE:  TypedElement JOIN•Property ANTI-­‐JOIN •Parameter C  :  Class C  :  Class  T  :  type •Variable  T  :  type§ Demonstra;on TE:  TypedElement o input:  UML  model TE:  TypedElement NEG o pa_ern:  UnusedClass UnusedClass(C) o change:  delete/retarget  type  reference
  33. 33. RETE  nets§ RETE  network o node:  (par;al)  matches   In-­‐memory  model of  a  (sub)pa_ern o edge:  update   (EMF  ResourceSet) propaga;onPATTERN INPUT INPUT INPUT C:  Class TE:  TypedElement C  :  Class C  :  ClassUnusedClass(C) Input  nodes  T  :  type TE:  TypedElement NEG T:  type TE:  TypedElement JOIN ANTI-­‐JOIN Intermediate   Produc;on   C  :  Class C  :  Class  T  :  type nodes  T  :  type§ Demonstra;on o input:  UML  model TE:  TypedElement node NEG TE:  TypedElement o pa_ern:  UnusedClass UnusedClass(C) o change:  delete/retarget  type  reference
  34. 34. RETE  nets§ RETE  network o node:  (par;al)  matches   of  a  (sub)pa_ern o edge:  update   propaga;onPATTERN INPUT INPUT INPUT C:  Class TE:  TypedElement C  :  Class C  :  ClassUnusedClass(C)  T  :  type TE:  TypedElement NEG T:  type TE:  TypedElement JOIN ANTI-­‐JOIN C  :  Class C  :  Class  T  :  type  T  :  type§ Demonstra;on TE:  TypedElement o input:  UML  model TE:  TypedElement NEG o pa_ern:  UnusedClass UnusedClass(C) o change:  delete/retarget  type  reference
  35. 35. RETE  nets  Class  objects§ RETE  network a b c o node:  (par;al)  matches   p s TypedElement.type  edges of  a  (sub)pa_ern x z w TypedElement  objects o edge:  update   propaga;onPATTERN INPUT INPUT INPUT C:  Class TE:  TypedElement C  :  Class C  :  ClassUnusedClass(C)  T  :  type x z w a b c TE:  TypedElement NEG T:  type p s TE:  TypedElement JOIN ANTI-­‐JOIN C  :  Class C  :  Class  T  :  type  T  :  type§ Demonstra;on TE:  TypedElement o input:  UML  model TE:  TypedElement NEG o pa_ern:  UnusedClass p x s z UnusedClass(C) o change:  delete/retarget  type  reference c
  36. 36. RETE  nets  Class  objects§ RETE  network a b c o node:  (par;al)  matches   p s TypedElement.type  edges of  a  (sub)pa_ern x z w TypedElement  objects o edge:  update   propaga;on pPATTERN INPUT INPUT INPUT C:  Class TE:  TypedElement C  :  Class C  :  ClassUnusedClass(C)  T  :  type x z w a b c TE:  TypedElement NEG T:  type p s TE:  TypedElement JOIN p ANTI-­‐JOIN C  :  Class C  :  Class  T  :  type  T  :  type§ Demonstra;on o input:  UML  model TE:  TypedElement p x TE:  TypedElement NEG o pa_ern:  UnusedClass p x s z UnusedClass(C) o change:  delete/retarget  type  reference c
  37. 37. RETE  nets  Class  objects§ RETE  network a b c o node:  (par;al)  matches   p s TypedElement.type  edges of  a  (sub)pa_ern x z w TypedElement  objects o edge:  update   propaga;on pPATTERN INPUT INPUT INPUT C:  Class TE:  TypedElement C  :  Class C  :  ClassUnusedClass(C)  T  :  type x z w a b c TE:  TypedElement NEG T:  type p s TE:  TypedElement JOIN p ANTI-­‐JOIN C  :  Class C  :  Class  T  :  type  T  :  type§ Demonstra;on o input:  UML  model TE:  TypedElement p x TE:  TypedElement NEG o pa_ern:  UnusedClass p x s z UnusedClass(C) o change:  delete/retarget  type  reference a c
  38. 38. RETE  nets  Class  objects§ RETE  network a b c o node:  (par;al)  matches   p s TypedElement.type  edges of  a  (sub)pa_ern x z w TypedElement  objects No4fica4onupdate   o edge:   propaga;on p Transparent:  user  modifica;on,  PATTERN results  oClass model  imports,   INPUT INPUT INPUT C:   f  a   TE:  TypedElement C  :  Class C  :  ClassUnusedClass(C) external   transforma;on,    T  :  type modifica;on,  …   x z w a b c TE:  TypedElement à RETE  is  always  updated! NEG T:  type p s TE:  TypedElement JOIN p ANTI-­‐JOIN C  :  Class C  :  Class  T  :  type  T  :  type§ Demonstra;on o input:  UML  model TE:  TypedElement p x TE:  TypedElement NEG o pa_ern:  UnusedClass p x s z UnusedClass(C) o change:  delete/retarget  type  reference a c
  39. 39. RETE  nets  Class  objects§ RETE  network a b c o node:  (par;al)  matches   p s TypedElement.type  edges of  a  (sub)pa_ern x z w TypedElement  objects No4fica4onupdate   o edge:   propaga;on p Transparent:  user  modifica;on,  PATTERN results  oClass model  imports,   INPUT INPUT INPUT C:   f  a   TE:  TypedElement C  :  Class C  :  ClassUnusedClass(C) external   transforma;on,    T  :  type modifica;on,  …   x z w a b c TE:  TypedElement à RETE  is  always  updated! NEG T:  type p s Experimental  results: TE:  TypedElement JOIN ANTI-­‐JOIN good,  if… C  :  Class p C  :  Class o There  is  enough    T  :  type  T  :  type§ Demonstra;on memory o input:  UML  modelmodel   TE:  TypedElement p x TE:  TypedElement NEG o Transac;onal   o pa_ern:  UnusedClass p x s z manipula;on UnusedClass(C) o change:  delete/retarget  type  reference a c
  40. 40. EMF-­‐INCQUERY  Architecture RETE  CorePa_ern/Query   EMF  INC  PM   VIATRA2  INC  PM spec Core Generated  PM  and  RETE   EMF  App builder
  41. 41. EMF-­‐INCQUERY  Tooling§ Genera;ve  approach o compile  queries  into   • RETE  network  builders • Query  interface  wrappers o end-­‐to-­‐end  solu;on:  generates  Eclipse  plug-­‐in  projects§ Relies  on  the  VIATRA2  environment o query  development o debugging  
  42. 42. Tooling  architectureDeclara;ve  Queries  in   3 Generated  Query   VIATRA2 Wrappers 4 EMF  App 2 VIATRA2   EMF  Modelmodel  representa;on 1 Development  ;me Run;me
  43. 43. Development  workflowImport  EMF  domain   Integrate  into  EMF   into  VIATRA2 applica;on Develop  and  test   Generate  INCQuery   queries  over   code VIATRA2
  44. 44. Development  workflowImport  EMF  domain   Integrate  into  EMF   into  VIATRA2 applica;on Automated Develop  and  test   Generate  INCQuery   queries  over   code VIATRA2
  45. 45. Development  workflowImport  EMF  domain   Integrate  into  EMF   into  VIATRA2 applica;on Automated Develop  and  test   Generate  INCQuery   queries  over   code VIATRA2 Supported  by   the  VIATRA2   IDE
  46. 46. Development  workflow Semi-­‐automated  for  typical   scenarios,  some  manual  codingImport  EMF  domain   Integrate  into  EMF   into  VIATRA2 applica;on Automated Develop  and  test   Generate  INCQuery   queries  over   code VIATRA2 Supported  by   the  VIATRA2   IDE
  47. 47. PART  1  -­‐  BASICS
  48. 48. Example  1§ Model  sta;s;cs§ Inspired  by  the  “model  measurement”  ATL  case   studies o h_p://www.eclipse.org/m2m/atl/usecases/ ModelsMeasurement/   o h_p://www.eclipse.org/m2m/atl/usecases/ Measuring_UML_models/  
  49. 49. Model  measures§ Total  number  of o Packages o Classes o A_ributes§ Number  of o Children o A_ributes o A_ributes  inherited§ …
  50. 50. Solu;on:  Development  workflowImport  EMF  domain   Integrate  into  EMF   into  VIATRA2 applica;on Develop  and  test   Generate  INCQuery   queries  over   code VIATRA2
  51. 51. DEMO Pa_ern  development  in  VIATRA2§ Create  IncQuery  project§ Import  the  UML  metamodel§ Import  UML  instance  models  § VTCL  development  environment o Create  and  debug  pa_erns o Visualize  pa_ern  matches o Test  queries/pa_erns  in  transforma;ons o Create  pa_erns  using  instance  model  “examples”
  52. 52. EXAMPLE Our  first  IncQueries
  53. 53. DEMO Genera;ng  IncQuery  code§ Generate o EMF-­‐IncQuery  Source  code:  Pa_ern  matchers o Sample  UI  project:  UI  integra;on§ Run  Sample  UI  project  commands  to  see  model   measures  
  54. 54. Generated  pa_ern  matchers§ INCQuery  run;me o Eclipse  plugin • Depends  only  on  EMF  and  the  INCQuery  core • No  VIATRA2  dependency!   o Private  code:  pa_ern  builders • Parameterize  the  RETE  core  and  the  generic  EMF  PM  library o Public  API:  Pa_ern  matcher  access  layer • Query  interfaces • Data  Transfer  Objects  (DTOs) • Used  to  integrate  to  EMF  applica;ons  
  55. 55. Generated  Sample  UI§ Command  contribu;ons o Project  explorer,  Naviga;on,  Package  Explorer o Perform  model  loading  and  query  execu;on o Display  the  results  on  the  UI • List  (default) – Pre_y  prints  a  list  of  matches • Counter – Prints  the  number  of  matches
  56. 56. IncQuery  Run;meGeneric  Query  API Generic  Change  APIGenerated  Query   Generated  Change   API API
  57. 57. Generated  Query  API§ Basic  queries o Uses  tuples  (object  arrays)  corresponding  to  pa_ern  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  pa_ern   signature
  58. 58. Query  Signatures§ Data  Transfer  Objects  generated   // B is a sibling class of A pattern siblingClass(C1, C2) = for   { pa_ern  signatures /* contents */§ Signature  query  methods } o SiblingClassSignature getOneMatch() o SiblingClassSignature getOneMatchAsSignature(Object C1, Object C2) public class SiblingClassSignature o Collection<SiblingClassSignature> { getAllMatchesAsSignature() Object C1; o Collection<SiblingClassSignature> getAllMatchesAsSignature(Object C1, Object C2; Object C2) }§ C1,  C2:  EObjects  or   datatype  instances   (String,  Boolean,  …)
  59. 59. Query  Signatures§ Data  Transfer  Objects  generated   // B is a sibling class of A pattern siblingClass(C1, C2) = for   { pa_ern  signatures /* contents */§ Signature  query  methods } o SiblingClassSignature getOneMatchAsSignature() o SiblingClassSignature getOneMatchAsSignature(UMLClass C1, public class SiblingClassSignature UMLClass C2) { o Collection<SiblingClassSignature> getAllMatchesAsSignature() UMLClass C1; o Collection<SiblingClassSignature> UMLClass C2; getAllMatchesAsSignature(UMLClass } C1, UMLClass C2)§ C1,  C2:  EObjects  or   Ongoing  work:  use   datatype  instances   domain-­‐specific  types   (String,  Boolean,  …) in  generated  code
  60. 60. Integra;ng  into  EMF  applica;ons§ Pa_ern  matchers  may  be  ini;alized  for o Any  EMF  No;fier • e.g.  Resources,  ResourceSets o (Transac;onalEdi;ngDomains)§ Ini;aliza;on o Possible  at  any  ;me o Involves  a  single  exhaus;ve  model  traversal   (independent  of  the  number  of  pa_erns,  pa_ern   contents  etc.)
  61. 61. Typical  programming  pa_erns1. Ini;alize  EMF  model o Usually  already  done  by  your  app  J2. Ini;alize  incremental  PM  whenever  necessary o Typically:  at  loading  ;me3. 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  changes4. Dispose  the  PM  when  not  needed  anymore o +  Frees  memory o -­‐  Re-­‐traversal  will  be  necessary
  62. 62. PART  2  –  VALIDATION  CASE  STUDY
  63. 63. Example  2§ Inspired  by  the  “Verifying  UML  profiled  models”   ATL  case  study o h_p://www.eclipse.org/m2m/atl/usecases/ Verifying_UML_profiled_models/  § Well-­‐formedness  checking  of  UML  models,  with  a   crucial  difference: o Incremental,  on-­‐the-­‐fly  valida;on o Maintain  error  markers  as  the  user  is  edi;ng  the  model
  64. 64. UML  well-­‐formedness  rules§ Tradi;onally  specified  by  OCL  constraints o Note:  OCL  constraints  included  in  UML  models  serve  a   different  purpose o OCL  constraints  can  be  a_ached  to  any  EMF  instance   model  via  EMF  Valida;on§ Rules  specified  by o Tool  developers o (End  users)
  65. 65. Well-­‐formedness  checking  from  a  tool  developer’s  perspec;ve§ Well-­‐formedness  rules o Express  constraints  not  (easily)  possible  by   metamodeling  techniques o Ensure  “sane”  modeling  conven;ons  &  best  prac;ces o Aid  code  genera;on  by  design-­‐;me  valida;on§ Example
  66. 66. Well-­‐formedness  checking  from  a  tool  developer’s  perspec;ve§ Well-­‐formedness  rules o Express  constraints  not  (easily)  possible  by   metamodeling  techniques o Ensure  “sane”  modeling  conven;ons  &  best  prac;ces o Aid  code  genera;on  by  design-­‐;me  valida;on§ Example
  67. 67. Well-­‐formedness  checking  from  a  tool  developer’s  perspec;ve§ Well-­‐formedness  rules o Express  constraints  not  (easily)  possible  by   metamodeling  techniques o Ensure  “sane”  modeling  conven;ons  &  best  prac;ces o Aid  code  genera;on  by  design-­‐;me  valida;on 2§ ExampleThe  number  of  parameters   of  a  Behavior’s  specifica;on  should  match   with  the  defini;on  of  the   1 Behavior  itself.
  68. 68. IncQuery  Valida;on  Engine§ Simple  valida;on  engine o Supports  on-­‐the-­‐fly  valida;on  through  incremental   pa_ern  matching  and  problem  marker  management o Uses  IncQuery  graph  pa_erns  to  specify  constraints§ Simulates  EMF  Valida;on  markers o To  ensure  compa;bility  and  easy  integra;on  with   exis;ng  editors o Doesn’t  use  EMF  Valida;on  directly • Execu;on  model  is  different
  69. 69. How  it  works  –  IncQuery  Change  API§ Track  changes  in  the  match  set  of  pa_erns  (new/lost)§ Delta  monitors o May  be  ini;alized  at  any  ;me o DeltaMonitor.matchFoundEvents / DeltaMonitor.matchLostEvents • Queues  of  matches  (tuples/Signatures)  that  have  appeared/disappeared   since  ini;aliza;on§ Typical  usage o Listen  to  model  manipula;on  (transac;ons) o A}er  transac;on  commits: • Evaluate  delta  monitor  contents  and  process  changes • Remove  processed    tuples/Signatures  from  .matchFound/LostEvents
  70. 70. Well-­‐formedness  rule  specifica;on  by  graph  pa_erns§ WFRs:  Invariants  which  must  hold  at  all  ;mes§ Specifica;on  =  set  of  elementary  constraints  +   context o Elementary  constraints:  Query  (pa_ern) o Loca;on/context:  a  model  element  on  which  the   problem  marker  will  be  placed§ Constraints  by  graph  pa_erns Match:   o Define  a  pa_ern  for  the  “bad  case” A  viola;on  of   the  invariant • Either  directly • Or  by  nega;ng  the  defini;on  of  the  “good  case” o Assign  one  of  the  variables  as  the  loca;on/context
  71. 71. EXAMPLE A  simple  UML  valida4on  constraint§ “All  Behaviors  must  have  an   Opera;on  as  their  specifica;on.” o Otherwise  they  do  not  have  any   “interface”  through  which  they  could  be   accessed  à  “dead  code”  § Bad  case:
  72. 72. EXAMPLE A  simple  UML  valida4on  constraint§ “All  Behaviors  must  have  an   Opera;on  as  their  specifica;on.” o Otherwise  they  do  not  have  any   “interface”  through  which  they  could  be   accessed  à  “dead  code”  § Bad  case: Iden;fy  pa_ern   variable  “Behavior”  as   the  loca;on
  73. 73. EXAMPLE A  simple  UML  valida4on  constraint§ “All  Behaviors  must  have  an   Opera;on  as  their  specifica;on.” o Otherwise  they  do  not  have  any   “interface”  through  which  they  could  be   accessed  à  “dead  code”  § Bad  case: Iden;fy  pa_ern   variable  “Behavior”  as   the  loca;on • Subs;tute  the  model  element  match  to  “Behavior”. • Syntax:  $Behavior.featureName$ • $Behavior$:  shortcut  for  $Behavior.name$
  74. 74. DEMO Constraint  code  genera;on§ Generate  sample  valida;on  project§ Observe  on-­‐the-­‐fly  valida;on  in  ac;on
  75. 75. Generated  Sample  Valida;on  project§ Java  classes:  Constraint  descendants§ Plugin.xml • Constraint  registra;on • UI  integra;on – Editor  ID  from  genmodel
  76. 76. Valida;on  lifecycle§ Constraint  viola;ons o Represented  by  Problem  Markers  (Problems  view) o Marker  text  is  updated  if  affected  elements  are   changed  in  the  model o Marker  removed  if  viola;on  is  no  longer  present§ Lifecycle o Editor  bound  valida;on  (markers  removed  when  editor   is  closed) o Incremental  maintenance  not  prac;cal  outside  of  a   running  editor
  77. 77. Valida;on  UI  integra;on§ A  menu  item  (command)  to  start  the  valida;on   engine§ Generic  (part  of  the  IncQuery  Valida;on   framework) o GMF  editor  command • Appears  in  all  GMF-­‐based  editor’s  context  menu o Sample  Reflec;ve  Editor  command • Appears  on  the  toolbar§ Generated o EMF  generated  tree  editor  command • Appears  on  the  toolbar
  78. 78. EXAMPLE A  complex  UML  constraint§ “Unused  signal” o A  Class  defines  a  Recep;on  for  a  Signal,  but  it  doesn’t   use  it  in  its  StateMachine  for  triggering  a  transi;on.§ Good  case:
  79. 79. EXAMPLE A  complex  UML  constraint§ “All  Recep;ons  of  a  Class  must  use  Signals  that  are   used  in  the  defining  Class’  StateMachine  as  a   Transi;on  Trigger.”§ Bad  case:
  80. 80. EXAMPLE A  complex  UML  constraint§ “All  Recep;ons  of  a  Class  must  use  Signals  that  are   used  in  the  defining  Class’  StateMachine  as  a   Transi;on  Trigger.”§ Bad  case: below  expresses  a   transi;ve   containment   rela;onship.
  81. 81. EXAMPLE A  complex  UML  constraint§ “All  Recep;ons  of  a  Class  must  use  Signals  that  are   used  in  the  defining  Class’  StateMachine  as  a   Transi;on  Trigger.” BELOW
  82. 82. EXAMPLE A  complex  UML  constraint§ “All  Recep;ons  of  a  Class  must  use  Signals  that  are   used  in  the  defining  Class’  StateMachine  as  a   Transi;on  Trigger.” Transi;ons  can  be  located   in  any  Region  of  the   StateMachine. BELOW
  83. 83. DEMO On-­‐the-­‐fly  valida;on  on  a  large  model§ Generate  Sample  Valida;on  code§ Load  modelGenera;onExample_2000.uml§ Observe  on-­‐the-­‐fly  valida;on o Performance  is  capped  by  the  Eclipse  Marker   management  layer.
  84. 84. EXAMPLE Extra  assignment§ The  number  of  parameters  of  a  Behavior’s   specifica;on  Opera;on  should  match  with  the   Behavior’s  defini;on.§ Bad  case: 2 1
  85. 85. EXAMPLE Solu;on Cardinality  constraints   expressing  the   “number  of  matches”
  86. 86. PERFORMANCE  BENCHMARKING
  87. 87. Challenges§ Performance  evalua;ons  are  hard o Fair? o Reliable? o Reproducible? o Can  the  results  be  generalized?§ Benchmark  example:   on-­‐the-­‐fly  constraint  valida;on  over  AUTOSAR  models o Conference  presenta;on  at  MODELS  2010 o Mo;va;on:  the  Embedded  Architect  Tool  of  OptXware  Ltd. o AUTOSAR  models  can  be  very  large  (>>1m  elements)
  88. 88. What  is  measured?§ Sample  models  were  generated o matches  are  scarce  rela;ve  to  overall  model  size§ On-­‐the-­‐fly  valida;on  is  modeled  as  follows: 1. Compute  ini;al  valida;on  results 2. Apply  randomly  distributed,  small  changes 3. Re-­‐compute  valida;on  results§ Measured:  execu;on  ;mes  of o Ini;aliza;on  (model  load  +  RETE  construc;on) o Model  manipula;on  opera;ons  (negligible) o Valida;on  result  (re)computa;on§ Compared  technologies o MDT-­‐OCL o Plain  Java  code  that  an  average  developer  would  write
  89. 89. IncQuery  Results§ Hardware:  normal  desktop  PC  (Core2,  4GB  RAM)§ Model  sizes  up  to  1.5m  elements§ Ini;aliza;on  ;mes  (resource  loading  +  first  valida;on) o <1  sec  for  model  sizes  below  50000  elements o Up  to  40  seconds  for  the  largest  model  (grows  linearly  with  the  model  size)§ Recomputa;on  ;mes 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  na;ve  code  /  OCL?
  90. 90. Ini;aliza;on  ;me
  91. 91. Ini;aliza;on  ;me •  Includes  ;me  for   first  valida;on •  Linear  func;on  of   model  size,  orders  of   magnitude  faster
  92. 92. Recomputa;on  ;me
  93. 93. Recomputa;on  ;me Recomputa;on  ;me   is  uniformly  near   zero (independent  of   model  size)
  94. 94. Performance  overview
  95. 95. Assessment  of  the  benchmark§ High  performance  complex  queries  are  hard  to   write  manually  in  Java.§ IncQuery  can  do  the  trick  nicely  as  long  as  you   have  enough  RAM.§ Metamodel  structure  has  huge  impact  on   performance  when  using  “conven;onal”  query   technologies  such  as  OCL,  due  to o Lack  of  reverse  naviga;on o Lack  of  type  enumera;on  (.allInstances())
  96. 96. Contribu;ons§ Expressive  declara;ve  query  language  by  graph  pa_erns o Capture  local  +  global  queries o Composi;onality  +  Reusabilility   o „Arbitrary”  Recursion,  Nega;on§ Incremental  cache  of  matches  (materialized  view) o Cheap  maintenance  of  cache  (only  memory  overhead) o No;fy  about  relevant  changes o Enable  reac;ons  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  a  desktop  PC)
  97. 97. CONCLUSION
  98. 98. Closing  thoughts§ On-­‐the-­‐fly  valida;on  is  only  one  scenario o Early  model-­‐based  analysis   o Language  engineering  in  graphical  DSMLs o Model  execu;on/analysis  (stochas;c  GT) o Tool  integra;on   o Model  op;miza;on  /  constraint  solving o …§ The  tutorial  examples o Do  not  make  use  of  advanced  features  such  as  parameterized   queries  or  complex  structural  constraints  (recursion) o Are  meant  only  as  a  star;ng  point o The  project  website  has  many  more  examples!
  99. 99. Model  transforma4ons  based  on  IncQuery§ High  performance  model  transforma;ons o Hybrid  query  approach • Use  IncQuery  for   – Complex  queries – Frequently  used  queries – Parameterized  queries • Plain  Java  for  simple  queries  (saves  RAM) o Java  for  control  structure  &  model  manipula;on§ High-­‐level  transforma;on  languages  (VIATRA2,  ATL,   Epsilon,  …)  could  be  “compiled”  to  run  on  this   infrastructure§ Ongoing  research:  automa;c  mapping  of  SPARQL,  OCL  &   others  to  the  IncQuery  language
  100. 100. Wish  list  IncQuery  features  J§ Declara;ve  query  language o Easy  to  learn o Good  bindings  to  the  impera;ve  world  (Java) o Safe  yet  powerful o Reusable§ High  performance o Fast  execu;on  for  complex  queries  over  large  models o First-­‐class  support  for  incremental  execu;on§ Technology o Works  with  EMF  out-­‐of-­‐the-­‐box
  101. 101. Pointers§ Open  source  project: o h_p://viatra.inf.mit.bme.hu/incquery§ VIATRA2  (grandfather) o h_p://eclipse.org/gmt/VIATRA2 o h_p://viatra.inf.mit.bme.hu§ István o rath@mit.bme.hu§ The  development  team o viatra-­‐dev@inf.mit.bme.hu o We’re  glad  to  help  with  any  problems  you  might  have. o Check  the  site  for  FAQ,  examples  &  more.§ Ques;ons  &  answers

×