-
Notifications
You must be signed in to change notification settings - Fork 1
Lecture 04
#EMF-IncQuery Incremental Evaluation of Model queries
- Motivation: early validation of design rules
##Design-rules/Well-formedness constraints
- e.g.: each valid car architecture needs to respect
- designers are immediately notified
- there are 500 (many)
- much more complex as first someone would think and evolved constantly
- emf doesn't support you to do so
##Domain Specific Modeling Languages Model size in practice: (App Model Size ) - System models: 10^8 - Sensor data: 10^9 - Geospatial model: 10^12
Why not push into a DB? Queries would include more than 10-15 joins!
###Model query:
- Query: set of constraints that have to be satisfied by (parts of) the (graph) model
- Result: set of model element tuple that satisfy the constraints of the queries
- Match: bind constant variables to model elements
Query(A,B) <- ^cond(A,B) header && body
##Graph Pattern Matching for Queries
complexity: |G|^|L| (often wrong in papers as well) - because the size of L is fixed
- m: L-> G (graph morphism)
- CSP
Local search: we use Ulman algorithm
- select first node to be matched
- order on edges
- try to find a corresponding match
- branch latter is better: push decision to down => decrease backtracking
- use: visitor pattern - visit nodes with visitor pattern
- Alternate search tree => based on the order of numbering
Increment: Performance of query evaluation
Query ~ : Execution time:
- Pattern/Query complexity
- Model size
- result set time: number of matches - if you calculate one it is simple
in design for 1 000 000 elements you will have matches under 100 (you are waiting to have)
Motivation for incremental graph pattern match
- More space less time
- cache all matches
- instantly retrieves match (if valid)
2 types:
- Batch query: designer select on demand, 1 or all
- Live query: automatically available
IncQuery(IQ): declarative query language
- each node or edge: became a predicate
- all constraints should be true (can imagine at the end of the line)
pattern (S:State, N)
neg find (x): you have a match for it if you don't have match for (x)
Transitive closure: ~ continues to find the pattern on the result e.g.: I have a family tree and apply transitive closure on childOf(...) the result is all my descendants
disjunction: { from == to } or{...}_
###Important:
- unreachable state: negative values don't substituted (like in prolog)
- patterns have to be connected
- check: everything can be in check, but it must not have side effects!!
- local: fixes one or more parameters (just search for my ancestors)
- and global query: iterates over everyone ( find every ancestor of every person)
##Development workflow:
- Develop EMF domain
- develop & test queries
- use/generate IncQuery code
- integrate into EMF application
Validation:
- you always capture the invalid case
- if you don't find a match than you don't have faults in it
antijoin : do the join as the usual way and throw away which has a join
incremental evaluation: will depend on the change not on model.
- If one pattern reuses the changed item, than you have to count all states which contains, the others you don't have to. (???)
- binding up a proper rete network is hard (rete means network in Italian)
- Eclipse basics
- EMF (incl. advanced topics)
- VIATRA Query
- Sirius
- Xtext+Xtend
- M2M
- Eclipse basics
- EMF (incl. advanced topics)
- VIATRA Query
- Sirius
- Xtext
- M2M
(Gradually replaced with updated content)
- Eclipse basics
- EGit
- EMF (incl. advanced topics)
- VIATRA Query
- Sirius
- Xtext
- M2M (VIATRA)
- Eclipse basics
- EGit
- EMF (incl. advanced topics)
- VIATRA Query
- Sirius
- Xtext
- M2M (VIATRA)