Model management tools contain common aspects that are frequently reinvented for each tool. Platform speci c solutions to common problems may vary by language, however, the high-level speci cations should be the same. Design patterns seek to communicate these common speci cations in an abstract way that enables reuse, improves understanding and eases communication. In this paper, we present a library of fundamental design patterns based on mathematical foundations that are used as building blocks to specify more complex patterns which describe more concrete model management scenarios.
Design patterns appear in many areas of software engineering including Object
Oriented (OO) design [
Although some work has been suggested in the literature relating to
design patterns for MMt, most of it has focused on model transformation (MT)
design patterns, and has been speci c to certain MT languages. In a notable
work [
Patterns 1-3 present a given con guration, and we call them static. In these patterns, we provide a clear separation between the information that is given (shown in black) and that being provided by a user or some heuristics (shown in green). In contrast, patterns 4-8 show operations, which take a con guration of models and mappings as their input (shown by shaded elements that are either black or green), and output a con guration of automatically computed models and mappings (blank blue elements). We call these patterns dynamic. Amongst them, patterns 4-6 are for source-to-target MTs, and patterns 7,8 are for the two types of model merge operations.
Pattern 1: Typing Mapping. A model is a total typing mapping (e.g., t1 in Fig.1) from a model's data graph (D1) to the model's metadata graph (M M1) (ovals in Fig.1). Typing must satisfy the constraints (C1) declared in the metamodel (we write t1 j= C1). Three vertical arrows in Fig.1 specify three models. Pattern 2: Model Mapping. A model mapping (e.g., f1 in Fig.1) is a pair (f1D, f1MM ) of total correspondence mappings between the respective data and metadata parts of the models. Together with the respective typing mappings, they form a commutative square of graph mappings. E.g., in Fig.1, we have two commutative squares (note the marker [=]) specifying two model mappings: fi : M0 ! Mi; i = 1; 2.
Pattern 3: Model Overlap. An overlap of two models is a span of model mappings. E.g, Fig.1 speci es a span (f1; f2) between models M1 and M2. Model M Mo, the head of the span, comprises correspondence links between models, and mappings fi; i = 1; 2 point to the ends of the links.
M1 MM1 t1 |= C1
D1 f1MM [=] f1D f2MM [=] f2D
M2
MM2 t2 |= C2
D2 Mo MMo to |= Co
Do Pattern 4: Descriptive Views. A view de nition is a metamodel mapping v1 : M M1 M Mo (see Fig.2). Its execution for model M1 is given by invoking the operation vExe (note the chevron), which takes instances of M M1 and outputs instances of M Mo.
Pattern 5: Prescriptive Views. Implementation of an instance of metamodel M Mo within a platform speci ed by M M2 is an operation opposite to view execution (see Fig.2), and unfolds over a view de nition mapping v2 : M Mo ! M M2. We call this operation source generation sGen. As view models (e.g., Mo) usually contain less information than source models (e.g., M2), a policy is required to choose a unique implementation amongst all possibilities.
Pattern 6: Model Transformation. A model transformation de nition is, in general, a span (v1; v2) of metamodel mappings, which can be executed in both directions. Fig.2 shows execution of the span in the direction from left to right, which transforms model M1 into model M2. The span can be also executed in the opposite direction with vExe for v2 and sGen over v1. View execution and source generation are two special cases, when either the right or the left \leg" of the transformation de nition span is the identity mapping.
Pattern 7: Additive Model Merge. An Additive Merge is the result of
executing a colimit operation on two models and their correspondence span, resulting
in a model together with two embedding mappings ei; i = 1; 2 (as seen in Fig.3),
whose inverse mappings provide traceability. This operation accurately merges
elements of the models without redundancy: if an element x from model M1 and
y from model M2 are linked in the correspondence span O, only one element
appears in the colimit M1 _ M2. Real model merge typically requires some
postprocessing for con ict resolution and normalization (see [
M1 MM1 :vExe f1D v2 f2D
M2
MM2
to |= Co :sGen
M1∨M2
M1
:limit
tr1
M1ΛM2
Pattern 8: Multiplicative Model Merge. A Multiplicative Merge is the
result of executing a limit operation on two models and their correspondence
co-span, resulting in a model together with two traceability mappings (see Fig.4)
to each of the input models. This pattern appears in scenarios that involve model
parallel composition, intersection or join. Details can be found in [
Consider the following MMt scenario: two models M 1,M 2 are matched, then merged, and the merge is translated into code. In our framework, the work ow is encoded as a composition of operations shown in Fig.(5). Semi-automatic (green) operation Match produces the correspondence span O, operation Merge (comprising colimit with some post-processing not shown in the gure) results in a triple (M 3; e1; e2), and operation Transf (whose de nition is not shown) produces M 4 with traceability mapping tr. Finally, applying operation limit to the cospan (e1; tr) outputs M14; the part of M 4 that depends on M 1. user input heuristics
O M1 M2 e1
e2
As an exercise, we encourage the workshop participants to consider the MDE design patterns they proposed in light of the patterns we presented here.