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

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

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

4. EXAMPLE: LABELLED TRANSITION SYSTEMS 22 July 2015Model Patterns 4 Label name: string Transition State init: bool sourcetarget 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 Label name: string Transition State out target label 1 1 LTS 1 init states + OCL constraint to avoid duplicate transitions Note: structural overhead in encoding (many additional labels)  

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

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

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

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

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

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

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

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

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

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

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

16. OPERATIONS 22 July 2015Model Patterns 16 Red: ForbiddenGreen: CreatedBlack: Read

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

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

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

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 2015Model Patterns 20 A f B !! A g B !! A g B f

21. PATTERN REFINEMENT 22 July 2015Model Patterns 21

22. COMMON PATTERN REFINEMENT: NODIFICATION 22 July 2015Model Patterns 22 Trans in: SetFunc Place 1 2 1 2 out: SetFunc Trans in: MapFunc Place 1 2 1 2 out: MapFunc int 3 3

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

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

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

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

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

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 2015Model Patterns 28

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

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