1 MODEL PATTERNS (WHAT STANDS IN THE WAY OF MORE WIDESPREAD ADOPTION OF MODEL-DRIVEN ENGINEERING?)...

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


Name Signature




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





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


Name Signature




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





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

1 MODEL PATTERNS (WHAT STANDS IN THE WAY OF MORE WIDESPREAD ADOPTION OF MODEL-DRIVEN ENGINEERING?)...

Documents

Transcript of 1 MODEL PATTERNS (WHAT STANDS IN THE WAY OF MORE WIDESPREAD ADOPTION OF MODEL-DRIVEN ENGINEERING?)...