Model Patterns 1
MODEL PATTERNS(WHAT STANDS IN THE WAY OF MORE WIDESPREAD ADOPTION OF MODEL-DRIVEN ENGINEERING?)Arend Rensink, University of TwenteECMFA Keynote, 22 July 2015
22 July 2015
Model Patterns 2
MODEL TECHNOLOGY: SMOOTH AND AWESOMEMODEL TECHNOLOGY: A TRIAL BALLOON
22 July 2015
Model Patterns 3
MOTIVATION 1: METAMODELS VERSUS MATH MODELS
Formal Methodists find metamodels hard to grasp How does a formal definition translate to a metamodel?
E.g. LTS: with and Typically: multiple options, none of which exactly fits What are the choices, and what are the consequences?
Model Engineers find mathematics hard to grasp Maze of twisty definitions, all different
Greek letters and other non-ASCII symbols Nevertheless, basic notions are just the same as in modelling
Just not available in a language they are familiar with
Global versus local view Mathematics: everything is available everywhere
E.g.: inverse functions, quantification over sets Metamodelling: only reachable things are available
Concepts of navigability, explicit opposites
22 July 2015
local view
global view
Model Patterns 4
EXAMPLE: LABELLED TRANSITION SYSTEMS
Mathematically: with and LTS , state set , transition set , global label set
Metamodellically:
22 July 2015
Labelname: string
Transition
Stateinit: bool
source target
label
1 1
1
Why does this not exactly fit?• Number of initial states not fixed at 1• Allows duplicate transitions
with same source + target + label
Labelname: string
Transition
State
outtarget
label
1
1
LTS
1init
states + OCL constraint to avoid duplicatetransitions
Note: structural overhead in encoding(many additional labels)
Model Patterns 5
MOTIVATION 2: THE POVERTY OF METAMODELS
Metamodel ingredients are quite low-level Labelled associations with multiplicities Orderedness/uniqueness for multi-valued associations Containment Opposites and association inheritance (poorly understood!) Last resort: OCL
This obfuscates the structure that is being modelled Everything looks the same No chance to specify conceptual level Risk: chosen implementation taken for intention Harder to refactor/refine/migrate
22 July 2015
Model Patterns 6
OUTLINE
Observed problems Gap between math and meta Conceptual poverty of meta
Proposed solution: Model patterns Statics (structure) Dynamics (operations)
Benefits Pattern refactoring and refinement Pattern recognition
Conclusion and discussion Don’t trust this solution, it hasn’t been tried in practice!
22 July 2015
Model Patterns 7
BY THEIR INSTANCES YOU WILL RECOGNISE THEM
Semantics of a metamodel? Extension = set of allowed instances So, first we define the universe of models
Assumed to be given: : Universe of node types, including data types int, bool, string : Universe of allowed edge labels : Universe of data values (infinite!)
Model: object graph = tuple : Set of nodes (always including all data values ) : Set of binary labelled edges : Edge source mapping (never a data value) : Edge target mapping : Node typing (respecting data types for )
Notation: for set of nodes of type
22 July 2015
Model Patterns 8
EXAMPLE: LABELLED TRANSITION SYSTEM
Usual concrete graphical syntax:
As model:
22 July 2015
put
get
put (lossy 1-place buffer)
Transition
State
target
label
LTS
State
Transition
TransitionLabelLabel
name = “put”
statesinit
out
out
out
target
target
label
states
label
“get”
name
Note: models can exist without meta-models!Formaldefinition
Usual syntax
Model Patterns 9
EXAMPLE PATTERN: TRIPLE
Metamodel level: hyperedge with name and pattern type
Model level: additional (math) structure on top of object graph In general: In this case: No concrete graphical syntax for triples
Default implementation Generic metamodel of : Instantiated in LTS metamodel
while substituting labels
22 July 2015
Labelname: string
StateLTS
1init
states 1 2
3trans: Triple
pattern name instantiatedpattern type
+ OCL
A
b
B
Triple
C
hasc
1 1
Model Patterns 10
INGREDIENTS OF A PATTERN (ROUND 1)
Name Signature
String of generic type names (act as formal parameters)
Specification Mathematical description of pattern structure
Implementation Metamodel (containing formal parameters) + OCL constraints This defines a set of allowed instances
Proof of correctness One-to-one mapping of metamodel instances to math structure
Note: Specification and proof of correctness are fixed once and for all Users of the pattern do not have to be aware Informal patterns are also usable (but offer no guarantees)
22 July 2015
Model Patterns 11
NATIVE METAMODEL PATTERNS
Multiplicities (outgoing and incoming): ? Zero or one edge arbitrary number of edges, possibly with duplicates + at least one edge, possibly with duplicates
22 July 2015
Af
B1
default
Function
Pattern: Func(A,B)
Partial function (undefined = null)
Pattern: PFunc(A,B)A
fB
?
Af
B1?
Injective function
Pattern: InFunc(A,B)
Surjective function
Pattern: SurFunc(A,B)A
fB
1+
Model Patterns 12
OTHER NATIVE METAMODEL PATTERNS
Multiplicities (outgoing and incoming): ! arbitrary number, no duplicates < arbitrary number of edges with ordering
22 July 2015
Af
B!
Set-valued function SetFunc(A,B)
OR binary relation Rel(A,B)
Multiset-valued function Af
B
List-valued function ListFunc(A,B)Af
B<
“unique”
“ordered”
How “native” is this, really?What does an instance of this pattern look like?
Model Patterns 13
IMPLEMENTATION ALTERNATIVES
Consider a sequence pattern Seq(A) (= list without gaps) Specification: , values or (empty sequence) Note: an instance represents a single, global sequence
Internal index: IdxSeq(A) Index field added to A-type
External index: XIdxSeq(A) Auxiliary Node-type with index
Internal pointer: PointSeq(A) next-pointer added to A-type
External pointer: XPointSeq(A) Auxiliary Node-type with pointer
Further alternatives Explicit (singleton) Seq-node, head- and tail-pointers Double-linked sequence
22 July 2015
Aidx
int1?
Nodeidx
int1?
A11
elem
Anext?
?
Nodenext?
?A
elem
1 1
+ OCL: consecutivevalue range
+ OCL: single headsingle tail
Model Patterns 14
SELECTING THE RIGHT ALTERNATIVE
“Right” alternative depends on modelling context Basic principle: choose the simplest possible (= cheapest)
representation However, if A-elements can occur multiple times or be shared
between sequences, external node is required
Determining factor: cost of operations Inserting a new element Retrieving an element by index (More about this later)
Choices can be reconsidered As long as pattern structure is remembered No need to think ahead to future extensions (More about this later)
22 July 2015
Model Patterns 15
OTHER EXAMPLE PATTERNS
Key(A,K) A-values uniquely identified by associated K-values Specification: injective function
Singleton(A) Specification: Implementation: «singleton» stereotype on A
Subset(A) Characterises subset of A-values Specification:
BinTree(N) Binary tree structure on node type N Specification:
22 July 2015
Aisin
bool1
Nleftright?
+ OCL: single head
Akey
K1?
Other GoF structural patterns!
Model Patterns 16
OPERATIONS
Every pattern has a set of standard operations E.g., append for extending a sequence with a new element Specification:
Every pattern implementation has to support them E.g., through graph transformation rules For IdxSeq (GROOVE syntax):
Empty sequence Non-empty sequence
For PointSeq:
Proof obligation: transformation conforms to specification Essentially, pattern implementation = algebra homomorphism
22 July 2015
Red: Forbidden Green: Created Black: Read
Model Patterns 17
WHAT’S WITH THESE OPERATIONS?
When you manipulate your instance model You want to know that you do it right The standard metamodel doesn’t tell you what is right Patterns impose conceptual structure, and so tell you what is right
Ideally, model manipulation is built from pattern operations Every rule, projected on a pattern instance, is a pattern operation This can be checked automatically
In practice, this may not always be feasible Pattern operations not executed atomically
E.g., A-element first added, then appended In that case, intermediate states may violate pattern
Pattern structure plays the role of invariant May be temporarily violated As long as violation is repaired afterwards
22 July 2015
Model Patterns 18
INGREDIENTS OF A PATTERN (ROUND 2)
Name Signature
String of generic type names (act as formal parameters)
Specification Mathematical description of pattern structure
Implementation Metamodel (containing formal parameters) + OCL constraints This defines a set of allowed instances
Operations Ideally: specification and implementation level Specification level is dispensible for (informal) use
Proof of correctness Mapping of metamodel instances to math structure Homomorphic with respect to operations
22 July 2015
Model Patterns 19
OUTLINE
Observed problems Gap between math and meta Conceptual poverty of meta
Proposed solution: Model patterns Statics (structure) Dynamics (operations)
Benefits Pattern refactoring and refinement Pattern recognition
Conclusion and discussion Don’t trust this solution, it hasn’t been tried in practice!
22 July 2015
Model Patterns 20
PATTERN REFACTORING
Replacing a pattern instance with an equivalent one Equivalent = implements the same pattern specification
Examples Replace IdxSeq(A) by PointSeq(A) or by XIdxSeq(A) Replace Rel(A,B) by Rel(B,A) or version with opposite edges
Model migration is implied Reasons for refactoring
Considerations of cost (operational complexity) Considerations of navigability (local versus global!)
Pattern equivalence can be proved formally Done only once, by pattern developer not model builder Knowledge is part of pattern library
22 July 2015
Af
B!
Ag
B!
Ag
Bf
Model Patterns 21
PATTERN REFINEMENT
Replacing a pattern with a more expressive one Default mapping from old pattern instances to new Non-injective mapping from new pattern instances to old left-inverse to
Example: replace IdxSeq(A) with IdxList(A) IdxList(A) allows gaps (null elements): with Implementation: index range need not be consecutive
: identity : remove all -elements from list
Example operation: Deletion of element i From IdxSeq(A): shift all elements with to From IdxList(A): replace with
Note: lengthoperation not preserved by
22 July 2015
Model Patterns 22
COMMON PATTERN REFINEMENT: NODIFICATION
From SetFunc(A,B) to MapFunc(A,B,C) (spec: ) C essentially encodes edge attribute type
Example: Petri Net Functions Every transition has sets of
input and output places
Refinement: Weighted Petri Net Every arc from place to transition
or vice versa has a weight Functions (Alternative: )
22 July 2015
Trans
in: SetFunc
Place
1
2
1
2out: SetFunc
Trans
in: MapFunc
Place
1
2
1
2
out: MapFunc
int
3 3
Model Patterns 23
PETRI NET REFINEMENT: INSTANCE LEVEL
Unweighted:
Weighted:
22 July 2015
TransPlace
PlaceTransin
in
outout
TransPlace
PlaceTransin
in
out
out
Inw = 1
tgt
Outw = 1
tgt
Outw = 1
tgt
Outw = 1
tgt
Model Patterns 24
INGREDIENTS OF A PATTERN (ROUND 3)
Name Signature
String of generic type names (act as formal parameters)
Specification Mathematical description of pattern structure
Implementation Metamodel (containing formal parameters) + OCL constraints This defines a set of allowed instances
Operations Ideally: specification and implementation level
Refinement relation with respect to other patterns Proof of correctness
Refinement pairs
22 July 2015
Model Patterns 25
PATTERN RECOGNITION
Given tool with a library of patterns An existing (concrete) metamodel can be scanned Every potential pattern instance can be detected The modeller can be asked if this is meant to be that pattern
Thus: reverse model engineering After which the benefits of patterns apply
22 July 2015
Model Patterns 26
OUTLINE
Observed problems Gap between math and meta Conceptual poverty of meta
Proposed solution: Model patterns Statics (structure) Dynamics (operations)
Benefits Pattern refactoring and refinement Pattern recognition
Conclusion and discussion Don’t trust this solution, it hasn’t been tried in practice!
22 July 2015
Model Patterns 27
PROPOSED PROGRAMME
Modelling tools should offer library of patterns Available for use to modeller Documentation of intended conceptual structure No obligation to use (modular extension)
Instantiated patterns give good old-fashioned metamodels But conceptual pattern layer remains available
Patterns help guide metamodel evolution Pattern refinement defines model migration Dynamics (operations) as well as statics (structure)
Optionally: pattern recognition Reverse engineer your existing metamodels Get all the benefits after the fact
22 July 2015
Model Patterns 28
RELATED WORK
More than I was aware of until very recently (as in yesterday) Model-Transformation Design Patterns
Kevin Lano, Shekoufeh Kolahdouz-Rahimi, IEEE SE Trans 2014
Patterns in Model Engineering (PaME 2015) ...
Please tell me about it!
22 July 2015
Model Patterns 29
WHAT STANDS IN THE WAY OF MORE WIDESPREAD ADOPTION OF MODEL-DRIVEN ENGINEERING?
Gap between math and meta Model patterns help to bridge the gap
Poverty of metamodels Model patterns improve conceptual structure
Difficulty of model migration Model patterns offer better handle on refactoring
Limited tool support Haha, you did not know I was going to say that! Panel session later today
Don’t trust this solution, it hasn’t been tried in practice! This was a sales pitch First you buy it, then I’ll build it
22 July 2015
Model Patterns 30
I want it
HOW DID YOU LIKE MY BALLOON?
22 July 2015
It’s great up here!
I want itI want it
Scenario 1 Scenario 2