2. LET’S WRITE A SIMULATOR
FOR PETRI NETS…
2
ins
Place
tokens: int
PetriNet
Transition
outs
places * trans*
*
*
operation Transition fire() {
for (p in self.ins) p.tokens-=1;
for (p in self.outs) p.tokens+=1;
}
…
3. DOES THIS LOOK FAMILIAR?
3
ins
Place
PetriNet
Transition
outs
places * trans*
*
*
Token
tokens *
operation Transition fire() {
for (p in self.ins)
p.tokens.remove(p.tokens.random());
for (p in self.outs)
p.tokens.add(new Token);
}
…
ins
Place
tokens: int
PetriNet
Transition
outs
places * trans*
*
*
operation Transition fire() {
for (p in self.ins) p.tokens-=1;
for (p in self.outs) p.tokens+=1;
}
…
4. NOT ONLY REALIZATIONS,
BUT VARIANTS…
4
ins
Place
tokens: int
bound: int
PetriNet
Transition
outs
places * trans*
*
*
Bounded places
ins
Place
tokens: int
PetriNet
Transition
outs
places * trans*
*
*
Transition priorities
priority: double
ins
Place
tokens: int
PetriNet
Transition
outs
places * trans*
*
*
Read arcs
read
* ins
Place
tokens: int
PetriNet
Transition
outs
places * trans*
*
*
Inhibitor arcs
inh
*
5. …WHICH WE MAY NEED TO
COMBINE
5
ins
Place
tokens: int
bound: int
PetriNet
outs
places * trans*
*
*
Bound + priorities (int)
Transition
priority: double
ins
Place
bound: int
PetriNet
outs
places * trans*
*
*
Bound + priorities
(class)
Transition
priority: double
Token
tokens *
ins
Place
PetriNet
Transition
outs
places * trans*
*
*
read
*
tokens: int
bound: int
Bound + read arcs (int)
ins
Place
PetriNet
Transition
outs
places * trans*
*
*
read
*
bound: int
Bound + read arcs
(class)Token
tokens *
6. ins
Place
tokens: int
bound: int
PetriNet
outs
places * trans*
*
*
Bound + priorities (int)
Transition
priority: double
ins
Place
bound: int
PetriNet
outs
places * trans*
*
*
Bound + priorities
(class)
Transition
priority: double
Token
tokens *
ins
Place
PetriNet
Transition
outs
places * trans*
*
*
read
*
tokens: int
bound: int
Bound + read arcs (int)
ins
Place
PetriNet
Transition
outs
places * trans*
*
*
read
*
bound: int
Bound + read arcs
(class)Token
tokens *
…WHICH WE MAY NEED TO
COMBINE
6
32 combinations
7. ins
Place
tokens: int
bound: int
PetriNet
outs
places * trans*
*
*
Bound + priorities (int)
Transition
priority: double
ins
Place
bound: int
PetriNet
outs
places * trans*
*
*
Bound + priorities
(class)
Transition
priority: double
Token
tokens *
ins
Place
PetriNet
Transition
outs
places * trans*
*
*
read
*
tokens: int
bound: int
Bound + read arcs (int)
ins
Place
PetriNet
Transition
outs
places * trans*
*
*
read
*
bound: int
Bound + read arcs
(class)Token
tokens *
…AND WRITE
TRANSFORMATIONS FOR
7
Now go and write
32 transformations
8. ins
Place
tokens: int
bound: int
PetriNet
outs
places * trans*
*
*
Bound + priorities (int)
Transition
priority: double
ins
Place
bound: int
PetriNet
outs
places * trans*
*
*
Bound + priorities
(class)
Transition
priority: double
Token
tokens *
ins
Place
PetriNet
Transition
outs
places * trans*
*
*
read
*
tokens: int
bound: int
Bound + read arcs (int)
ins
Place
PetriNet
Transition
outs
places * trans*
*
*
read
*
bound: int
Bound + read arcs
(class)Token
tokens *
…AND MAINTAIN
8
Do we add weights
to the arcs?
10. WHAT WE NEED
A succinct mechanism to express meta-model variants
Methods to write transformations for all these variants
• Compact: without writing many similar-but-not-quite-the-
same transformations
• Usable: abstract away from details of other variants
• Extensible: easy to add new variants
• Correct: express and check expectations on different parts of
the transformation
10
11. OUR CONTRIBUTION
11
A notion of transformation product line (TPL), which is:
• Compact: transformation fragments, annotated with their activation
(presence) conditions
• Usable: abstraction mechanism that hides details (concepts)
• Extensible: by composition operators
• Correct: by profiting from (OCL) contracts and analysis methods
based on model finding
Building on a notion of meta-model product line (MMPL) [GLCS18]
Tool support: Merlin
Experiments that show the benefits of analysis at the TPL level
[GLCS18] Guerra, de Lara, Chechik, Salay. 2018.
Analysing Meta-Model Product Lines. Proc. SLE, pp.: 171-184.
12. META-MODEL PRODUCT LINES:
FEATURE MODEL
Feature model to express the variability space
Features and their allowed combinations
Feature diagram
Configurations
12
mandatory optional
alternative or
PetriNets
Tokens
Simple Object
Priority
FM = {PetriNets, Tokens, Simple, Object, Arcs, Inhibitor, Read, Priority, Bounded},
PetriNets Tokens Arcs ((Simple ¬Object) (¬Simple Object))
Arcs
Inhibitor Read
Bounded
Legend
P = {⟨Simple⟩, ⟨Simple, Inhibitor, Bounded⟩, ⟨Object, Read, Priority⟩, . . . }
(32 are possible, only leaf features shown)
13. META-MODEL PRODUCT LINES:
150% META-MODEL
13
ins
Place
itokens: int
bound: int
PetriNet
Transition
outs
places
Simple
1
* trans*
1
Token
ctokens
*
1
Object
Object
*
* priority: double
read*
Read
Priority
*
inh Inhibitor
Bounded
boundedTokens1 inv:
itokens<=bound
Bounded Simple
boundedTokens2 inv:
ctokens→size()<=bound
Bounded Object
“meta-model” with presence conditions
Upon selecting a configuration, a meta-model is derived:
• Having only those elements (classes, attributes, referemces,
constraints) whose presence condition is true
14. META-MODEL PRODUCT LINES:
150% META-MODEL
14
ins
Place
itokens: int
bound: int
PetriNet
Transition
outs
places
Simple
1
* trans*
1
Token
ctokens
*
1
Object
Object
*
* priority: double
read*
Read
Priority
*
inh Inhibitor
Bounded
boundedTokens1 inv:
itokens<=bound
Bounded Simple
boundedTokens2 inv:
ctokens→size()<=bound
Bounded Object
“meta-model” with presence conditions
ins
Place
itokens: int
bound: int
PetriNet
outs
places * trans*
*
*
Transition
priority: double
⟨Simple, Bounded, Priority⟩
boundedTokens1 inv:
itokens<=bound
Bounded Simple
15. NEED FOR
ABSTRACTION
15
ins
Place
itokens: int
bound: int
PetriNet
Transition
outs
places
Simple
1
* trans*
1
Token
ctokens
*
1
Object
Object
*
* priority: double
read*
Read
Priority
*
inh Inhibitor
Bounded
boundedTokens1 inv:
itokens<=bound
Bounded Simple
boundedTokens2 inv:
ctokens→size()<=bound
Bounded Object
We are stating
the same
constraint for
two different
variants
Find a way to abstract away the differences of different realizations
Simplify writing constraints and transformations
• Ensuring scaling with variant combinations
16. CONCEPTUAL MMPLs
Make uniform the 150% meta-model
Concept on top of the 150% meta-model
• A canonical representation of common elements
• Binding to different variants
Express expectations on the different variants (constraints)
16
ins
Place
tokens: int
PetriNet
Transition
outs
places * trans*
*
*
posTokens inv:
self.tokens >= 0
PetriNet
+places(): Place[*]
+trans(): Transition[*]
Place
+tokens(): int
Transition
+ins(): Place[*]
+outs(): Place[*]
posTokens inv:
self.tokens() >= 0
17. context PetriNet
def: places() : Place[∗] = self.places
def: trans() : Transition[∗] = self.trans
context Transition
def: ins() : Place[∗] = self.ins
def: outs() : Place[∗] = self.outs
context Place
[Simple] def: tokens() : Integer = self.itokens
[Object] def: tokens() : Integer = self.ctokens→size()
PL OF BINDINGS
17
Constraints and transformations are written against the concept
Now we can write one constraint, instead of two (with simpler PC):
context Place
[Bounded] inv boundedTokens: self.tokens()<=bound
PetriNet
+places(): Place[*]
+trans(): Transition[*]
Place
+tokens(): int
Transition
+ins(): Place[*]
+outs(): Place[*]
posTokens inv:
self.tokens() >= 0
18. TRANSFORMATION
PRODUCT LINES (TPLs)
18
Tranformation Definition
• Meta-model
• Rule signatures and contracts (specification)
• Rule bodies
Transformation Product Line (TPL)
• Transformation Definition with variability (bodies with PCs)
19. BOUNDED TPLs
19
Tranformation Definition
• Meta-model
• Rule signatures and contracts (specification)
• Rule bodies
Transformation Product Line (TPL)
• Transformation Definition with variability (bodies with PCs)
Bounded TPL
• TPL coupled with a CMMPL
21. TPL EXAMPLE
21
operation PetriNet step() : Boolean {
var enabledTrans = self.trans()->select(enabled());
if (enabledTrans->isEmpty()) return false;
else return self.pick(enabledTrans).fire() ;
}
[Simple] operation Place modify(t : Integer) {
self.itokens += t;
}
[Object] operation Place modify(t : Integer) {
if (t>0)
for (i in Sequence{1..t})
self.ctokens.add(new Token);
else if (t<0)
for (i in Sequence{1..-t})
self.ctokens.remove(self.ctokens.random());
}
22. EXTENDING TPLs
22
context PetriNet
[not Priority] def: pick(s: Set(Transition)): Transition= s→any(true)
[Priority] def: pick(s: Set(Transition)): Transition=
s→any(t | not s→exists(t1| t1.priority>t.priority))
context Transition
[not (Inhibitor or Read or Bounded)]
def: enabled() : Boolean = self.ins()→forAll(tokens()>0)
[Inhibitor and not (Read or Bounded)]
def: enabled() : Boolean = self.ins()→forAll(tokens()>0) and
self.inh→forAll(tokens()=0)
[Inhibitor and Read and not Bounded]
def: enabled() : Boolean = self.ins()→forAll(tokens()>0) and
self.inh→forAll(tokens()=0) and
self.read→forAll(p.tokens()>0)
… (5 more combinations ommited)
Still difficult to extend!
23. COMPOSING RULE BODIES
OVERRIDING
Override: declares precedence among rule bodies
• Default (super): more specific body overrides more general body
• Other semantics: subs, all
23
context PetriNet
def: pick(s: Set(Transition)): Transition =
s→any(true)
context PetriNet
[Priority]
−− @Override super
def: pick(s: Set(Transition)): Transition=
s→any(t | not s→exists(t1| t1.priority>t.priority))
24. Merge operators depending on rule signature
• and/or for boolean queries, union/intersection for collections
• Arithmetical operations for queries returning numbers
• Sequential composition of actions for operations changing state
24
context Transition
def: enabled(): Boolean = ins()→forAll(tokens()>0)
COMPOSING RULE BODIES
MERGE
context Transition
−− @Merge and
[Inhibitor] def: enabled(): Boolean = inh→forAll(tokens()=0)
context Transition
−− @Merge and
[Read] def: enabled(): Boolean = read→forAll(tokens()>0)
context Transition
−− @Merge and
[Bounded] def: enabled(): Boolean=outs()→forAll(tokens()<bound)
4combinations
insteadof8
25. ANALYSIS
Syntactic
• CMMPL and TPL well-formedness:
• No binding/rule body collisions
• No missing bindings/bodies
• Analysing each derivable meta-model/transformation is prohibitive!
• Technique: SAT solving
Semantic
• CMMPL Consistency
• Does some derivable meta-model violate the concept invariants?
• TPL contracts
• Analysing each derivable meta-model/transformation is prohibitive!
• Technique: Lift model finding to TPL
25
26. LIFTING MODEL
FINDING TO PLS
Model finders
• Input: meta-model +
OCL invariants +
search bound
• Output: valid instance
model (or none)
• USE Validator
Feature explicit meta-model
• Embed the feature model in the meta-model
• Emulate the PCs with OCL invariants
• The result is a valid model, which includes an object representing a
configuration
26
28. TOOL SUPPORT
Merlin: http://miso.es/tools/merlin/
• Eclipse plugin
Meta-model product lines + transformation product lines
Analysis based on model finding (USE Validator)
• Other analyses: Sat4J
• OCL syntactical correctness
Independent on the transformation
language
• OCL (queries, analysis), can be
mixed with any other language
• EOL
• ETL, EGL (experimental)
28
30. VALIDATION
RQ1: How much specification effort do TPLs save?
Most derivable transformations are different
TPL size (in LOC) considerable smaller than the total size of
every transformation
30
31. VALIDATION
RQ2: How much analysis effort do TPLs save?
31
• Extension of the
example (256 configs)
• CMMPL Consistency
analysis
• 20 versions, with
increasing #MMs
violating the invariant
• Comparison with
enumerative approach
10x to 120x faster if <3% MMs violate the invariant
Faster than enumerative (avg) if <42% MMs violate the invariant
Faster than enumerative (worst) if <90% MMs violate the invariant
Only marginally slower (ms) when all MMs violate the invariant
32. CONCLUSIONS
New notion of transformation product lines (TPLs)
• On top of meta-model product lines (MMPLs)
• Coupled via concepts (abstraction mechanism)
• Transformation specification (contracts)
• Extensibility: composition operators
• Analysis and Verification support (model finding)
Tool support (Merlin)
• Independent on the transformation language
Experiments showing good results
• TPLs are succinct, analysis is efficient
TPLs as (closed) reuse mechanism
32
33. FUTURE WORK
Apply this notion to other MDE artefacts:
• Model-to-model transformations and code generators (already)
• Editors (graphical, textual)
Better support for contract analysis
Lift other verification techniques, e.g., based on static analysis
Testing!
Refactoring for TPLs
• Factor out common code to concept
33