Tutorial at EC-MFA 2011.

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
Group
Budapest
University
of
Technology
and
Economics
Department
of
Measurement
and
Informa<on
Systems

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. 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. MOTIVATION
While
you’re
downloading
J

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. Hi
Jane,
what
do
you
do
at
work?
Jane

7. Hi
Jane,
what
do
you
do
at
work?
Jane

8. Hi
Jane,
what
do
you
do
at
work?
Jane
Boss

9. Hi
Jane,
what
do
you
do
at
work?
Jane
Detect
Boss
Constraint

10. Hi
Jane,
what
do
you
do
at
work?
Jane
Detect
Report
Boss
Constraint

11. Hi
Jane,
what
do
you
do
at
work?
Jane
Detect
Report
View
Boss
Constraint

12. Hi
Jane,
what
do
you
do
at
work?
Jane
Detect
Gen
Report
View
Boss
Constraint

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. 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. 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. 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. STATE
OF
THE
ART

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. 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. 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. EMF-­‐IncQuery
§ Expressive
declara;ve
query
language
by
graph
pa_erns
§ Incremental
cache
of
matches
(materialized
view)
§ High
performance
for
large
models

22. INCQUERY
TECHNOLOGY
OVERVIEW

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. 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. 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. 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. Pa_ern
defini;on Graphical
nota;on
implements
pa_ern
siblingClass(C1,C2)
UI
Model superClass
S:
Class S GComp Cmd Iface
S1: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. Graph
pa_erns
(VTCL)
// B is a sibling class of A
siblingClass(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. Graph
pa_erns
(VTCL)
// B is a sibling class of A
siblingClass(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 A
locallySubs
(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. 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. RETE
nets
§ RETE
network
o node:
(par;al)
matches
of
a
(sub)pa_ern
o edge:
update
propaga;on
PATTERN INPUT INPUT INPUT
C:
Class TE:
TypedElement C
:
Class C
:
Class
UnusedClass(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. RETE
nets
§ RETE
network
o node:
(par;al)
matches
of
a
(sub)pa_ern
o edge:
update
propaga;on
PATTERN INPUT INPUT INPUT
C:
Class TE:
TypedElement C
:
Class C
:
Class
UnusedClass(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. RETE
nets
§ RETE
network
o node:
(par;al)
matches
In-­‐memory
model
of
a
(sub)pa_ern
o edge:
update
(EMF
ResourceSet)
propaga;on
PATTERN INPUT INPUT INPUT
C:
Class TE:
TypedElement C
:
Class C
:
Class
UnusedClass(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. RETE
nets
§ RETE
network
o node:
(par;al)
matches
of
a
(sub)pa_ern
o edge:
update
propaga;on
PATTERN INPUT INPUT INPUT
C:
Class TE:
TypedElement C
:
Class C
:
Class
UnusedClass(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. 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
PATTERN INPUT INPUT INPUT
C:
Class TE:
TypedElement C
:
Class C
:
Class
UnusedClass(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. 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 p
PATTERN INPUT INPUT INPUT
C:
Class TE:
TypedElement C
:
Class C
:
Class
UnusedClass(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. 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 p
PATTERN INPUT INPUT INPUT
C:
Class TE:
TypedElement C
:
Class C
:
Class
UnusedClass(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. 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
:
Class
UnusedClass(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. 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
:
Class
UnusedClass(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. EMF-­‐INCQUERY
Architecture
RETE
Core
Pa_ern/Query
EMF
INC
PM
VIATRA2
INC
PM
spec Core
Generated
PM
and
RETE
EMF
App
builder

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. Tooling
architecture
Declara;ve
Queries
in
3 Generated
Query
VIATRA2 Wrappers
4 EMF
App
2
VIATRA2
EMF
Model
model
representa;on 1
Development
;me Run;me

43. Development
workflow
Import
EMF
domain
Integrate
into
EMF
into
VIATRA2 applica;on
Develop
and
test
Generate
INCQuery
queries
over
code
VIATRA2

44. Development
workflow
Import
EMF
domain
Integrate
into
EMF
into
VIATRA2 applica;on
Automated
Develop
and
test
Generate
INCQuery
queries
over
code
VIATRA2

45. Development
workflow
Import
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. Development
workflow
Semi-­‐automated
for
typical
scenarios,
some
manual
coding
Import
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. PART
1
-­‐
BASICS

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. Model
measures
§ Total
number
of
o Packages
o Classes
o A_ributes
§ Number
of
o Children
o A_ributes
o A_ributes
inherited
§ …

50. Solu;on:
Development
workflow
Import
EMF
domain
Integrate
into
EMF
into
VIATRA2 applica;on
Develop
and
test
Generate
INCQuery
queries
over
code
VIATRA2

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. EXAMPLE Our
first
IncQueries

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. 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. 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. IncQuery
Run;me
Generic
Query
API Generic
Change
API
Generated
Query
Generated
Change
API API

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. 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. 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. 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. Typical
programming
pa_erns
1. Ini;alize
EMF
model
o Usually
already
done
by
your
app
J
2. Ini;alize
incremental
PM
whenever
necessary
o Typically:
at
loading
;me
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

62. PART
2
–
VALIDATION
CASE
STUDY

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. 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. 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. 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. 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
§ Example
The
number
of
parameters
of
a
Behavior’s
specifica;on
should
match
with
the
defini;on
of
the
1
Behavior
itself.

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. 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. 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. 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. 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. 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. DEMO Constraint
code
genera;on
§ Generate
sample
valida;on
project
§ Observe
on-­‐the-­‐fly
valida;on
in
ac;on

75. Generated
Sample
Valida;on
project
§ Java
classes:
Constraint
descendants
§ Plugin.xml
• Constraint
registra;on
• UI
integra;on
– Editor
ID
from
genmodel

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. 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. 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. 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. 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. 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. 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. 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. 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. EXAMPLE Solu;on
Cardinality
constraints
expressing
the
“number
of
matches”

86. PERFORMANCE
BENCHMARKING

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. 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. 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. Ini;aliza;on
;me

91. Ini;aliza;on
;me
•
Includes
;me
for
first
valida;on
•
Linear
func;on
of
model
size,
orders
of
magnitude
faster

92. Recomputa;on
;me

93. Recomputa;on
;me
Recomputa;on
;me
is
uniformly
near
zero
(independent
of
model
size)

94. Performance
overview

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

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