MODEL PATTERNS WHAT STANDS IN THE WAY OF

MODEL PATTERNS (WHAT STANDS IN THE WAY OF MORE WIDESPREAD ADOPTION OF MODEL-DRIVEN ENGINEERING ? ) Arend Rensink, University of Twente ECMFA Keynote, 22 July 2015 Model Patterns 1

MODEL TECHNOLOGY: A SMOOTH TRIAL BALLOON AND AWESOME Model Patterns 22 July 2015 2

MOTIVATION 1: METAMODELS VERSUS MATH MODELS § global view local view Model Patterns 22 July 2015 3

EXAMPLE: LABELLED TRANSITION SYSTEMS § State init: bool 1 source 1 target Transition label states State LTS init 1 out 1 target Transition label Model Patterns Why does this not exactly fit? • Number of initial states not fixed at 1 • Allows duplicate transitions with same source + target + label 1 Label name: string + OCL constraint to avoid duplicate transitions Note: structural overhead in encoding (many additional labels) 1 Label name: string 22 July 2015 4

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 Model Patterns 22 July 2015 5

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! Model Patterns 22 July 2015 6

BY THEIR INSTANCES YOU WILL RECOGNISE THEM § Model Patterns 22 July 2015 7

EXAMPLE: LABELLED TRANSITION SYSTEM § Usual concrete graphical syntax: put (lossy 1 -place buffer) get § As model: LTS states Label name “get” Formal definition label states init target State target out Transition label out Transition target label Label name = “put” Usual syntax State Note: models can exist without meta-models! Model Patterns 22 July 2015 8

EXAMPLE PATTERN: TRIPLE § states State LTS init 1 1 2 3 trans: Triple Label name: string instantiated pattern type pattern name has + OCL Triple c b 1 A Model Patterns B 1 C 22 July 2015 9

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) Model Patterns 22 July 2015 10

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 f A 1 f A A A ? f ? 1 f + 1 B B Model Patterns default 22 July 2015 11

OTHER NATIVE METAMODEL PATTERNS § Multiplicities (outgoing and incoming): ú ! arbitrary number, no duplicates ú < arbitrary number of edges with ordering A A A f ! f f < “unique” “ordered” B B B How “native” is this, really? What does an instance of this pattern look like? Model Patterns 22 July 2015 12

IMPLEMENTATION ALTERNATIVES § A A A ? idx ? 1 elem 1 1 ? next int Node + OCL: consecutive value range idx ? 1 int + OCL: single head single tail elem ? A Node 1 1 next ? Model Patterns 22 July 2015 13

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) Model Patterns 22 July 2015 14

OTHER EXAMPLE PATTERNS § A A N ? key ? 1 isin 1 left right K bool + OCL: single head Other Go. F structural patterns! Model Patterns 22 July 2015 15

OPERATIONS § Red: Forbidden Green: Created Model Patterns Black: Read 22 July 2015 16

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 Model Patterns 22 July 2015 17

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 Model Patterns 22 July 2015 18

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! Model Patterns 22 July 2015 19

PATTERN REFACTORING § Replacing a pattern instance with an equivalent one ú Equivalent = implements the same pattern specification § Examples ú Replace Idx. Seq(A) by Point. Seq(A) or by XIdx. Seq(A) ú Replace Rel(A, B) by Rel(B, A) or version with opposite edges f g f B A B A g ! ! § 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 Model Patterns 22 July 2015 20

PATTERN REFINEMENT § Model Patterns 22 July 2015 21

COMMON PATTERN REFINEMENT: NODIFICATION § Trans in: Set. Func 1 1 2 2 out: Set. Func Place Trans in: Map. Func 1 3 2 1 out: Map. Func 2 3 Place int Model Patterns 22 July 2015 22

PETRI NET REFINEMENT: INSTANCE LEVEL § Unweighted: in Place Trans out in Trans § Weighted: Place tgt Place In w = 1 in tgt out Out w = 1 tgt Out w = 1 out Trans in Model Patterns Out tgt w = 1 Place 22 July 2015 23

INGREDIENTS OF A PATTERN (ROUND 3) § Model Patterns 22 July 2015 24

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 Model Patterns 22 July 2015 25

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! Model Patterns 22 July 2015 26

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 Model Patterns 22 July 2015 27

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 (Pa. ME 2015) §. . . ú Please tell me about it! Model Patterns 22 July 2015 28

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 Model Patterns 22 July 2015 29

HOW DID YOU LIKE MY BALLOON? It’s great up here! Scenario 1 I want it Scenario 2 I want it Model Patterns 22 July 2015 30