Budapest University of Technology and Economics Department of Measurement and Informa<on Systems Budapest University of Technology and Economics Fault Tolerant Systems Research Group A TUTORIAL ON EMFINCQUERY 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ó
101
Embed
EMF-INCQuery Incremental evaluation of model …mit.bme.hu/~rath/ppt/EMF-IncQuery_Tutorial_ECMFA11_Rath.pdfBudapestUniversityof)TechnologyandEconomics Department)of)Measurement)and)Informa
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Budapest University of Technology and EconomicsDepartment of Measurement and Informa<on Systems
Budapest University of Technology and EconomicsFault Tolerant Systems Research Group
A TUTORIAL ON EMF-‐INCQUERYIncremental 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ó
Contents§ Mo;va;on
o Model queries…?o State of the art of EMF model querieso 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 UMLo Integra;on with Papyrus UML
§ Conclusiono Performance benchmarkso Q&A
§ Feel free to ask ques4ons along the way!
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 UMLh_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
o = Execu;on ;me, as a func;on of• Query complexity• Model size / contents• Result set size
§ Incrementalityo Don’t forget previously computed results!oModels 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.
Model query engine wish list§ Declara;ve query language
o Easy to learno Good bindings to the impera;ve world (Java)o Safe yet powerfulo Reusable
§ High performanceo Fast execu;on for complex queries over large modelso First-‐class support for incremental execu;on
§ TechnologyoWorks with EMF out-‐of-‐the-‐box
STATE OF THE ART
Problem 1: Expressiveness§ EMF Query (declara;ve)
o Low expressivenesso Limited navigability• no „cycles”
§ OCL (declara;ve)o Verbose o Lack of reusability supporto Local constraints of a model element
o Poor handling of recursionàChallenging to use
Problem 2: Incrementality§ Goal: Incremental evala;on of model queries
o Incremental maintenance of result seto 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 EMFo Research MT tools: with varying degrees of support
Problem 3: Performance§ Na;ve EMF queries (Java program code): Lack of o Reverse naviga;on along referenceso Enumera;on of all instances by typeo Smart Caching
§ Scalability of (academic) MT toolso Queries over >100K model elements (several proofs): FUJABA, VIATRA2 (Java), GrGEN, VMTS (.NET), Egyed’s tools
EMF-‐IncQuery§ Expressive declara;ve query language by graph pa_erns
§ Incremental cache of matches (materialized view)
§ High performance for large models
INCQUERY TECHNOLOGY OVERVIEW
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
Contribu;ons§ Expressive declara;ve query language by graph pa_erns
o Capture local + global querieso Composi;onality + Reusabilility o „Arbitrary” Recursion, Nega;on
§ Incremental cache of matches (materialized view)
§ High performance for large models
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/VIATRA2o h_p://wiki.eclipse.org/VIATRA2
o Structural condi;on that have to be fulfilled by a part of the model space
§ Graph pa_ern matching:o A model (i.e. part of the model space) can
sa;sfy a graph pa_ern, o if the pa_ern can be matched to a
subgraph of the model
Graph pa_erns (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);
A: Class B: Class
P: Class
s1:superClass s2:superClass
siblingClass(A,B)
Graph pa_erns (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 pa_ern
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);
OR pa_ern
Contribu;ons§ Expressive declara;ve query language by graph pa_erns
o Capture local + global querieso 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
o Collection<SiblingClassSignature> getAllMatchesAsSignature()
o Collection<SiblingClassSignature> getAllMatchesAsSignature(Object C1, Object C2)
§ C1, C2: EObjects or datatype instances (String, Boolean, …)
public class SiblingClassSignature{ Object C1; Object C2;}
// B is a sibling class of A pattern siblingClass(C1, C2) = { /* contents */ }
Query Signatures
Ongoing work: use domain-‐specific types in generated code
public class SiblingClassSignature{ UMLClass C1; UMLClass C2;}
§ Data Transfer Objects generated for pa_ern signatures
§ Signature query methodso SiblingClassSignature
getOneMatchAsSignature()o SiblingClassSignature
getOneMatchAsSignature(UMLClass C1, UMLClass C2)
o Collection<SiblingClassSignature> getAllMatchesAsSignature()
o Collection<SiblingClassSignature> getAllMatchesAsSignature(UMLClass C1, UMLClass C2)
§ C1, C2: EObjects or datatype instances (String, Boolean, …)
// B is a sibling class of A pattern siblingClass(C1, C2) = { /* contents */ }
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;ono Possible at any ;meo Involves a single exhaus;ve model traversal (independent of the number of pa_erns, pa_ern contents etc.)
Typical programming pa_erns1. Ini;alize EMF model
o Usually already done by your app J
2. Ini;alize incremental PM whenever necessaryo Typically: at loading ;me
3. Use the incremental PM for querieso Model updates will be processed transparently, with minimal
performance overheado Delta monitors can be used to track complex changes
4. Dispose the PM when not needed anymoreo + Frees memoryo -‐ Re-‐traversal will be necessary
PART 2 – VALIDATION CASE STUDY
Example 2§ Inspired by the “Verifying UML profiled models” ATL case studyo 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;onoMaintain error markers as the user is edi;ng the model
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 markerso 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
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 ;meo DeltaMonitor.matchFoundEvents / DeltaMonitor.matchLostEvents• Queues of matches (tuples/Signatures) that have appeared/disappeared since ini;aliza;on
§ Typical usageo 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
Well-‐formedness rule specifica;on by graph pa_erns
§ WFRs: Invariants which must hold at all ;mes§ Specifica;on = set of elementary constraints + contexto Elementary constraints: Query (pa_ern)o Loca;on/context: a model element on which the problem marker will be placed
§ Constraints by graph pa_ernso Define a pa_ern for the “bad case”• Either directly• Or by nega;ng the defini;on of the “good case”
o Assign one of the variables as the loca;on/context
Match: A viola;on of the invariant
EXAMPLE
§ “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:
A simple UML valida4on constraint
EXAMPLE
§ “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:
A simple UML valida4on constraint
Iden;fy pa_ern variable “Behavior” as
the loca;on
EXAMPLE
§ “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:
A simple UML valida4on constraint
• Subs;tute the model element match to “Behavior”.• Syntax: $Behavior.featureName$• $Behavior$: shortcut for $Behavior.name$
Iden;fy pa_ern variable “Behavior” as
the loca;on
DEMO§ Generate sample valida;on project§ Observe on-‐the-‐fly valida;on in ac;on
o Performance is capped by the Eclipse Marker management layer.
On-‐the-‐fly valida;on on a large model
EXAMPLE
§ The number of parameters of a Behavior’s specifica;on Opera;on should match with the Behavior’s defini;on.
§ Bad case:
Extra assignment
2
1
EXAMPLE Solu;on
Cardinality constraints expressing the
“number of matches”
PERFORMANCE BENCHMARKING
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 modelso Conference presenta;on at MODELS 2010o Mo;va;on: the Embedded Architect Tool of OptXware Ltd.o AUTOSAR models can be very large (>>1m elements)
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 results2. Apply randomly distributed, small changes3. Re-‐compute valida;on results
§ Measured: execu;on ;mes ofo Ini;aliza;on (model load + RETE construc;on)o Model manipula;on opera;ons (negligible)o Valida;on result (re)computa;on
§ Compared technologieso MDT-‐OCLo Plain Java code that an average developer would write
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 elementso Up to 40 seconds for the largest model (grows linearly with the model size)
§ Recomputa;on ;meso Within error of measurement (=0), independent of model sizeo Retrieval of matches AND complex changes is instantaneous
§ Memory overheado <50 MB for model sizes below 50000 elementso Up to 1GB for the largest model (grows linearly with model size)
§ How does it compare to na;ve code / OCL?
Ini;aliza;on ;me
Ini;aliza;on ;me
• Includes ;me for first valida;on• Linear func;on of model size, orders of magnitude faster
Recomputa;on ;me
Recomputa;on ;me
Recomputa;on ;me is uniformly near
zero(independent of model size)
Performance overview
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 too Lack of reverse naviga;ono Lack of type enumera;on (.allInstances())
Contribu;ons§ Expressive declara;ve query language by graph pa_erns
o Capture local + global querieso 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 changeso Enable reac;ons to complex structural events
§ High performance for large modelso Linear overhead for loading o Instant response for querieso > 1 million model elements (on a desktop PC)
CONCLUSION
Closing thoughts§ On-‐the-‐fly valida;on is only one scenario
o Early model-‐based analysis o Language engineering in graphical DSMLso Model execu;on/analysis (stochas;c GT)o Tool integra;on o Model op;miza;on / constraint solvingo …
§ The tutorial exampleso Do not make use of advanced features such as parameterized queries or complex structural constraints (recursion)
o Are meant only as a star;ng pointo The project website has many more examples!
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
Wish list IncQuery features J§ Declara;ve query language
o Easy to learno Good bindings to the impera;ve world (Java)o Safe yet powerfulo Reusable
§ High performanceo Fast execu;on for complex queries over large modelso First-‐class support for incremental execu;on