Elementary Model Management Patterns Sahar Kokaly1 , Zinovy Diskin1,2 , Tom Maibaum1 , Hamid Gholizadeh1 1 NECSIS, McMaster University, Canada {kokalys|diskinz|maibaum|mohammh}@mcmaster.ca 2 University of Waterloo, Canada zdiskin@gsd.uwaterloo.ca Model management tools contain common aspects that are frequently reinvented for each tool. Platform specific solutions to common problems may vary by lan- guage, however, the high-level specifications should be the same. Design patterns seek to communicate these common specifications in an abstract way that en- ables reuse, improves understanding and eases communication. In this paper, we present a library of fundamental design patterns based on mathematical foun- dations that are used as building blocks to specify more complex patterns which describe more concrete model management scenarios. 1 Introduction Design patterns appear in many areas of software engineering including Object Oriented (OO) design [5] and workflow languages [1], and can be used for model management (MMt) as well. Indeed, MMt tools address common issues, whose solutions are frequently reinvented for each tool. Platform specific solutions to common problems may vary by language, however, the high-level specifications could be the same. Design patterns seek to communicate these common spec- ifications in an abstract way that enables reuse, improves understanding, and eases communication. Although some work has been suggested in the literature relating to de- sign patterns for MMt, most of it has focused on model transformation (MT) design patterns, and has been specific to certain MT languages. In a notable work [4], the authors propose a platform independent language for describing patterns for graph-based MTs. In [6], the author discusses transformation pat- terns for refactoring/improving/implementing OO designs. In our earlier work [2], we presented a library of abstract design patterns for MMt based on mathe- matical foundations. Rather than suggesting patterns for entire MMt scenarios (as is done for OO design in [5] and for MT in [4]), we proposed elementary building-block-patterns, from which complex patterns for MMt scenarios can be composed. The goal of this short paper is to introduce the library to the PAME community, and present it in a condensed and simplified way (Section 2). How our elementary patterns are composed into complex scenarios is shown by an example in Section 3. 2 Elementary Design Patterns In our presented design patterns, mappings are made explicit and are defined as sets of links (block arrows) between model elements rather than single links between models. Moreover, the algebraic operations (appearing on chevrons) in the patterns generate models as well as explicit traceability maps. Patterns 1-3 present a given configuration, 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 configuration of models and mappings as their input (shown by shaded elements that are either black or green), and output a configuration 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 meta- model (we write t1 |= 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 , f1M M ) 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 map- pings. E.g, Fig.1 specifies 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 Mo M2 MM1 MMo f2MM MM2 f1MM t1 |= C1 to |= Co t2 |= C2 [=] [=] D1 f1D Do f2D D2 Fig. 1. Patterns 1,2,3 2 Pattern 4: Descriptive Views. A view definition 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 out- puts instances of M Mo . Pattern 5: Prescriptive Views. Implementation of an instance of metamodel M Mo within a platform specified by M M2 is an operation opposite to view exe- cution (see Fig.2), and unfolds over a view definition 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 definition 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 definition span is the identity mapping. M1 Mo M2 MM1 v1 MMo v2 MM2 t1 |= C1 :v E x to |= Co t2 |= C2 e :s G en D1 f1D Do f2D D2 Fig. 2. Patterns 4,5,6 Pattern 7: Additive Model Merge. An Additive Merge is the result of execut- ing 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 post- processing for conflict resolution and normalization (see [2] for details). 3 O f1 M2 O f1 M2 f2 :col f2 :lim imit e2 it tr2 M1 e1 M1∨M2 M1 tr1 M1ΛM2 Fig. 3. Pattern 7 Fig. 4. Pattern 8 Pattern 8: Multiplicative Model Merge. A Multiplicative Merge is the re- sult 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 [3]. 3 Example 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 workflow 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 figure) results in a triple (M 3, e1, e2), and operation Transf (whose definition 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. M14 tr 1 4:limit tr 2 user input M1 e1 heuristics h tr tc 1: Ma O M4: e M3 erg s f Code 2: M ran M2 e2 3:T Fig. 5. Workflow example. 4 Concluding Remarks As an exercise, we encourage the workshop participants to consider the MDE design patterns they proposed in light of the patterns we presented here. 4 References 1. van der Aalst, W.M.P.: Workflow patterns. In: Encyclopedia of Database Systems, pp. 3557–3558 (2009) 2. Diskin, Z., Kokaly, S., Maibaum, T.: Mapping-Aware Megamodeling: Design Pat- terns and Laws. In: SLE. pp. 322–343 (2013) 3. Diskin, Z., Maibaum, T.: A model management imperative: being graphical is not sufficient, you have to be categorical. (To appear in ECMFA’15) 4. Ergin, H., Syriani, E.: Towards a language for graph-based model transformation de- sign patterns. In: Theory and Practice of Model Transformations - 7th International Conference, ICMT 2014, York, UK, July 21-22, 2014. pp. 91–105 (2014) 5. Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design patterns: elements of reusable object-oriented software. Pearson Education (1994) 6. Lano, K., Kolahdouz-Rahimi, S.: Design patterns for model transformations. In: IC- SEA 2011, The Sixth International Conference on Software Engineering Advances. pp. 263–268 (2011) 5