Co-Transformation of Graphs and Type Graphs With Application to Model Co-Evolution⋆ (Long Version) Gabriele Taentzer1 , Florian Mantz2 , Yngve Lamo2 1
Philipps-Universit¨ at Marburg, Germany
[email protected] 2 Bergen University College, Norway {fma,yla}@hib.no
Abstract. Meta-modeling has become the key technology to define do– main-specific modeling languages in model-driven engineering. Since do– main-specific modeling languages often change quite frequently, concepts are needed for the coordinated evolution of their meta-models as well as of their models, and possibly other related artifacts. In this paper, we present a new approach to the co-transformation of graphs and type graphs and show how it can be applied to model co-evolution. This means that models are specified as graphs while model relations, especially type-instance relations, are defined by graph morphisms specifying type conformance of models to their meta-models. Hence, meta-model evolution and accompanying model migrations are formally defined by co-transformations of instance and type graphs. In our approach, we clarify the type conformance of co-transformations, the completeness of instance graph transformations wrt. their type graph modifications, and the reflection of type graph transformations by instance graph transformations. Finally, we discuss strategies for automatically deducing instance graph transformation rules from given type graph transformations. Keywords: meta-model evolution, model migration, graph transformation
1
Introduction
Model-driven engineering (MDE) is a software engineering discipline that uses models as the primary artifacts throughout software development processes and adopt model transformation both for their optimization as well as for model and code generation. Models in MDE describe application-specific system design which is automatically translated into code. A commonly used technique to define modeling languages is meta-modeling. In contrast to traditional software development where programming languages rarely change, domain-specific ⋆
This work was partially funded by NFR project 194521 (FORMGRID)
2
modeling languages, and therefore meta-models, often change frequently: modeling language elements may be, e.g., renamed, extended by additional attributes, or refined by a hierarchy of sub-elements. The evolution of a meta-model requires the consistent migration of its models (See Fig. 1) which is a considerable research challenge in MDE [18].
✄ ✂ Meta-model ✁ O conforms to
evolution
✄ / Meta-model′ ✂ ✁ O conforms to
✄ ✄ migration _ _ _ _ _ _ _ +3 Model′ Model ✂ ✁ ✂ ✁ Fig. 1. Meta-model evolution and model migration
Since graphs and graph transformations are conceptually close to models and model transformations, we consider instance and type graph co-transformations as a suitable approach to the formalization of model co-evolution. In contrast to the traditional double pushout (DPO) approach in [4] where deletion of graph parts is performed before the creation of new graph elements, we use the dual approach where creation is done before deletion. The dual approach has been introduced as co-span DPO-approach in [5] which also shows equivalence of both approaches. We choose this variant of graph transformations because they allow better synchronization of deletion and creation actions than the usual DPO approach, since the intermediate graphs contain both elements to be deleted and those to be added. Since we do not want to restrict ourselves to a specific kind of graph and graph morphism in this paper, the theoretical concepts and results are formulated at the level of (weak) adhesive categories (see e.g. [9,3]). On this basis, we characterize co-transformations that lead to type conforming result graphs. Considering a given type graph transformation, a related instance graph transformation has to be complete, i.e., has to incorporate the whole instance graph, and has to reflect at least deletion actions of the type graph level. Furthermore, we present a strategy to deduce instance graph transformation rules from given type graph transformations. The new graph transformation concepts and results presented are clearly motivated by our wish to develop an adequate formalization of model and metamodel co-evolution. Among existing approaches [17,19,2,8,14,16] only [16] contains fundamental results about the well-formedness of model and meta-model co-evolutions. However, the co-evolution approach presented in [16] is more restricted than ours. The rest of the paper is organized as follows: in Section 2, we introduce a simple model co-evolution scenario. The definition of co-span transformation is recalled in Section 3 which prepares for the formalization of model and meta-model
3
co-evolution presented in Section 4. We conclude this paper with a consideration of related work in Section 5 and final remarks in Section 6.
2
A co-evolution scenario
To motivate our approach, we consider a well-known Petri Net meta-model evolution scenario as presented in [2,19,14]. Figure 2 shows this scenario together with an example model migration. While the upper row presents two evolution steps of the meta-model, the lower row shows the migration of a small Petri net modeling a communication between “Alice” and “Bob”. Note that the meta-model defines abstract syntax structures, while the example Petri nets are given in concrete syntax. Figure 2 shows two co-evolution steps: in the first step weights are added to outgoing and incoming arrows, in the second step the place-transitions nets are extended to coloured nets. First step: since meta classes are needed to hold meta attributes, meta references “outArr” and “inArr” are replaced by classes “OutArr” and “InArr” as well as two additional references. In addition, attribute “weight” is added to “OutArr” first and then extracted to superclass “Arr”. Second step: the token attribute of class “Place” is extracted into a new associated class “Token” as number “attribute”. In addition class “Token” gets a new additional attribute “type”. The corresponding migration can be performed fully automatically. We choose to set values for new “weight” as well as “type” attributes to a default value. Afterwards a modeler may change this value. In Fig. 2, for example, the modeler changed the weight value at the outgoing transition of “to Alice” to “2” to express that Alice gets more input than Bob.
Fig. 2. A small co-evolution scenario based on Petri nets
4
3
Co-span transformation
Graph transformation is the rule-based manipulation of graphs. There exists a variety of graph transformation approaches, differing mainly in the kind of transformation rules allowed and the way in which they are applied. A standard approach is the algebraic graph transformation [3] where graph parts are deleted first and then new elements are added. In the following, we consider the co-span approach [5], i.e., a variant where actions are applied in the reverse order. Graphs are often used as an abstract representation of models. When formalizing object-oriented modeling, graph structures are used for modeling and meta-modeling leading to instance and type graphs. A fixed type graph T G serves as an abstract representation of a meta-model. As in object-oriented modeling, types can be structured by a generalization relation. Multiplicities and other annotations are not formalized by type graphs, but have to be expressed by additional graph constraints [6,15]. When considering meta-model conformance, we will neglect constraints for now, but we will take them into account in the future. Instance graphs define model structures and have structure-preserving mappings to their type graphs. The attribution of graph nodes and edges can be achieved by using data algebras. In that case, a type graph contains exactly one element per data type formalized by the final algebra. (For details on typed attributed graphs see [4,3].) Considering the algebraic graph transformation approach, rules are roughly expressed by two graphs L and R, where L is the left-hand side of the rule and R is the right-hand side, which are usually overlapping in graph parts. Rule graphs may contain variables for attributes. The left-hand side L represents the preconditions of the rule, while the right-hand side R describes its post-conditions. The intersection L ∩ R (the graph part that is not changed) and the union L ∪ R should both form graphs, i.e., they must be compatible with source, target and type settings, in order to apply the rule. Graph L\(L∩R) defines the part that is to be deleted, and graph R \ (L ∩ R) defines the part to be created. Furthermore, the application of a graph rule may be restricted by so-called negative application conditions (NACs) which prohibit the existence of certain graph patterns in the current instance graph. Graph elements common to L and R or common to L and a NAC, are indicated by the same name or number. (Graph inclusions are generalized to injective graph morphisms in the following definitions.) r,m +3 H between two instance graphs G A direct graph transformation G and H is defined by first finding a match m of the left-hand side L of rule r in an instance graph G such that m is structure-preserving, type-compatible, and satisfies the NACs (i.e., the forbidden graph patterns are not found in G). Attribute variables used in a graph object o ∈ L are bound to concrete attribute values of graph object m(o) in G. The resulting graph H is usually constructed by first removing all graph items from G that are in L but not also in R and second adding all those new graph items that are in R but not in L. This kind of graph transformation is formalized by the standard double pushout (DPO) approach as presented in [3].
5
However, this is not the only possible order to perform graph changes. It is possible to reverse this order which seems to better fit the needs of model co-evolution. By first adding new meta-model elements while keeping the ones to be deleted, the intermediate meta-model can be used for both, continuous typing of migrating models as well as synchronizing required migration changes. See example 4 for more details. Meta-model elements that are to be deleted, are removed in the second step. This form of transformation is called co-span DPO approach and presented in [5]. We recall the main definitions here, abstracting from the concrete graph category, and assuming graph structures and morphisms that form a (weak) adhesive category C with a selected class M of monomorphisms. Adhesive (weak-adhesive) categories C fulfill the following properties: class M is closed under isomorphisms, composition, and decomposition. C has pushouts and pullbacks along M-morphisms, i.e., if one of the given morphisms is in M, pushouts and pullbacks over these morphisms exist. Given a pushout (P OA ) with l ∈ M as below, then morphism g ∈ M and pushout (P OA ) is also a pullback. Pushouts in C along M-morphisms are (weak) Van-Kampen-squares if the following holds: Consider a commutative cube like the left cube in Fig. 4: If the top is a pushout along M-morphism and the back as well as the left squares as pullbacks, the following statement holds: The bottom square is a pushout along M-morphism iff the front and the right squares are pullbacks. For weak Van-Kampen-squares, morphisms m and l or tG , tU , and tI have to be in M. Definition 1 (Co-span transformation). Let C be a category with pushouts l
r
along class M of morphisms. An co-span rule p = L −→ I ←− R consists of structures L, I and R and M-morphisms l and r which are jointly epiL l /Io r R morphic. Given a morphism m : L → G, called match, rule p can be applied to G if a cospan doublem (P OA ) i (P OB ) m′ pushout exists as shown in the diagram below. p,m G g /U o h H t : G =⇒ H is called a co-span transformation. If rule p and its match m are given, then pushout (P OB ) has to be constructed m′
h
as pushout complement R → H → U . This is possible if the co-span gluing condition is satisfied. In the category of graphs, we define each node of L whose image under m is source or target of a context edge in G as boundary node. The gluing condition is satisfied if boundary nodes are preserved by the rule. Formally, the co-span gluing condition is defined as follows: Definition 2 (Cospan gluing condition). Given morphism m : L → G, let b : B → L be the boundary of m, i.e., the “smallest” morphism such that there is a pushout complement of b and m. Then, m satb′ isfies the cospan gluing condition wrt. rule p = (=) ' l r L −→ I ←− R if there is a morphism b′ : B → R B b /L l /Io r R ′ with r ◦ b = l ◦ b. p,m
If the gluing condition is satisfied for m wrt. p, then t : G =⇒ H exists and is unique. (For more details see [5].) A co-span transformation t is typed over a
6
structure T G if there are typing morphims from G and all structures belonging to the rule to T G such that they commute. In this case, also H can be typed over T G in a compatible way. Remark 1. It is shown in [3] that attributed, typed graphs with total graph morphisms are adhesive with a dedicated class M of injective morphisms. Category AGraphT G of typed, attributed graphs with class M consisting of injective graph morphisms with isomorphisms on their data algebras, are shown to be adhesive in [4]. Considering typed graphs with node type inheritance, Theorem 1 in [7] shows that the corresponding category is weak adhesive if class MS−ref l contains injective morphisms being also subtype-reflecting meaning that for a mapped type, all its sub-types are also mapped. This result is extended to the category AIGraphs of attributed graphs with node type inheritance with class AMS−ref l of S-reflecting attributed clan morphisms in Theorem 6 in [7]. (This category is used in all the following examples.) Example 1 (Co-span graph transformation). Figure 3 shows an example for a co-span graph transformation taking up again the Petri net evolution scenario of Fig. 2. An “inArr”- edge of our example Petri net model is replaced by an “InArr”-node with weight “1” and adjacent edges. This migration step is shown in detail using the abstract syntax of Petri net models. The numbers in nodes and at edges indicate how morphisms are defined. Please note the special numbering of attributed nodes. Not only nodes but also their attributes and attribute values are numbered, since attributes are formally defined by edges and attribute values by data nodes (see [3] for more details). In the theory there are always all possible data values, however in all figures there are only those values shown that are also attribute values. The co-span gluing condition is fulfilled in this example, since edges only are deleted.
4
Formalization of model and meta-model co-evolution
In this section, we formalize meta-model evolution and corresponding model migrations based on co-span transformation. 4.1
Co-evolutions by co-transformations
Formalizing a meta-model evolution and a corresponding model migration by two coupled co-span transformations, their correspondence has to be clarified. They are type conforming if a model migration can be typed over its meta-model evolution, i.e. if all corresponding models are in consistent type-instance relations. Formally, this means that we take the category of typed attributed graphs and that there are typing graph morphisms between each pair of corresponding graphs commuting with each other. However, this does not mean that instance graphs are always transformed such that modifications on the instance level exactly correspond to type graph modifications. To ensure a meaningful instance graph transformation, the match
7
Fig. 3. Example: A co-span graph transformation
of an instance graph rule has to cover all graph parts typed over type graph elements taking part in the evolution. They can be formally determined by the pullback over the instance graph typing morphism and the match on type level. In this case, the migration rule match is called match complete. Furthermore, an instance rule has to reflect at least those deletions specified by its type rule. For example, an instance rule not doing anything, does not always reflect a type rule adequately, since potential deletions may not be performed and the resulting instance graph would not be well-typed over the resulting type graph, since elements with old types remain in the graph. However, creations in type graphs do not have to be (fully) reflected in corresponding instance graphs. Moreover, the action reflection of type rules in instance rules can be characterized by two pullbacks over both rules and their typing morphisms. We call co-transformations fulfilling this requirement action-reflecting. tp,tm
Definition 3 (co-transformation). Two co-span transformations tt : T G =⇒ p,m
tl
tr
l
r
T H and t : G =⇒ H with rules tp = T L −→ T I ←− T R and p = L −→ I ←− R form a co-transformation (tt, t), if there are morphisms tG : G → T G , tU : U → T U , and tH : H → T H as well as tL : L → T L, tI : I → T I, and tR : R → T R such that all squares in Fig. 4 commute. tp,tm In such a co-transformation (tt,t), transformation tt : T G =⇒ T H is called p,m an evolution while transformation t : G =⇒ H is called a migration wrt. tt. Definition 4 (evolution-reflecting migration). A co-transformation (tt, t) tL m T L is a pullback as presented in Fig. 4 is called match-complete if G ←− L −→ tR tL l r T R are pullbacks. We L −→ I and I ←− R −→ and action-reflecting if T L ←−
8
tl
TL
tr
TI
tm
P O1tt
TR
ti
tL
P O2tt
tR
tg
TG
th
TU
TH
l
L
r
I
tG
R
tU m
G
tm′
tI
tH
P O1t
i
g
U
P O2t
m′
h
H
Fig. 4. Co-transformation
say that migration t is match-complete and action-reflecting wrt. evolution tt, or short, t is evolution-reflecting wrt. tt. Example 2. In this example, we consider again the meta-model evolution scenario for Petri nets introduced in Section 2 and formalize it: In Fig. 5, an excerpt of the meta-model evolution step E1 of Fig. 2 is presented as a co-span graph transformation. Before this graph transformation is applied, the “outArr” reference has already been replaced by a “OutArr” class and also weight attribute has been added and extracted to a superclass “Arr”. In the co-span rule presented in Fig. 5, reference “inArr” is replaced by a new subclass “InArr” of class “Arr”. The whole transformation is typed over a simple graph representing the meta-meta-model structure. It consists of a graph node, a graph edge which is a loop on the graph node, a data node, and an attribute edge between the graph and the attribute node. The typing over this graph is not shown explicitly by morphisms but implicitly by a special graphical notation. Graph nodes are depicted by rounded rectangles, graph edges by arrows, and attribute edges and nodes by placeholders left and right to the “:=” inside graph node rectangles. In graphs T G, T U, and T H, node and edge names are depicted, since they are used as type names in corresponding migrations. Actually, these type names are not necessary, since typing is determined by graph morphisms only. However, to increase the readability we represent the typing of model graphs and migration rule graphs redundantly by type names and numbers. Figure 6 shows the migration of the Petri net model triggered by the previously shown meta-model evolution rule in detail. Although similar to the one in Fig. 3, this migration is match-complete, since both “inArr” edges are matched.
9
Fig. 5. Example: A meta-model evolution
Fig. 6. Example: A match-complete, action-reflecting migration
The migration in Fig. 3 is not match-complete, since only one “inArr” edge is matched, but still action-reflecting. In addition, the rule in Fig. 3 is not a valid migration since not all elements of deleted types are also deleted by the migration rule. Please note that the numbering in Fig. 6 is consistent with that in Fig. 5 so that both figures together form an example for the complete doublecube shown in Fig. 4. In the evolution transformation, types identified by the same “set of numbers” are related. Likewise in the migration transformation, el-
10
ements identified by the same “numbers” are related. Furthermore each element of the migration is mapped to that type including the corresponding number. Theorem 1 (existence and uniqueness of co-transformation). Given two tp,tm
p,m
co-span transformations tt : T G =⇒ T H and t : G =⇒ H together with typing morphisms tG : G → T G, tL : L → T L, tI : I → T I, and tR : R → T R such that migration t is match-complete and action-reflecting wrt. evolution tt, then, structures U and H can be uniquely typed by morphisms tU : U → T U and tH : H → T H resp. such that (tt, t) forms a co-transformation. (Compare Fig. 4.) Proof. First, we show that tU : U → T U exists. Since Def. 3 ensures that PO1 is a pushout and since we assume match-completeness and action-reflection, we have tm ◦ tL = tG ◦ m and tl ◦ tL = tI ◦ l. It follows that tg ◦ tG ◦ m = ti ◦ tI ◦ l and therefore the universal property holds for P O1t , i.e., there is a unique tU : U → T U with tU ◦ g = tg ◦ tG and tU ◦ i = ti ◦ tI . Consider the left cube of Fig. 4: since the back and the left squares are pullbacks by assumption (due to match-completeness and action-reflection), and the top and bottom squares are pushouts also by assumption, the front and the right squares are pullbacks, due to the Van-Kampen-square property [9]. Now, we show that graph morphism tH exists and is unique by using the VanKampen-square again. Consider the cube below: first, we construct the pullback (y, z) of (th, tU ). Due to action-reflection the back square is a pullback. The top square is a pullback since it is pushout along M-morphisms (see Th. 4.26 in [3]). Since the left, top and back squares are pullbacks, we get th ◦ tm′ ◦ tR = tU ◦ i ◦ r. Therefore, there is a unique morphism x : R → P BO by the universal property of pullback (y, z) such that the bottom and the right squares commute. Since the back and top squares are pullbacks, their combination is one. Since in addition the front is a pullback, the bottom is one, due to pullback decomposition properties. The bottom and the left squares are pullbacks, therefore their combinatr TO I o TR tion is one. Furthermore the top square w O z ti zzz tm′ www w is a pullback, the right square is also one, zz ww |zz {ww again due to pullback decomposition th o tR TH O O tI properties. Applying the Van-Kampen- T U square, we can conclude that the bottom square is a pushout. It differs from the r tU Io bottom square in Fig. 4 by the pushout z z wR ww zz i x w z complement. Since it is a pushout and w z ww zz {ww since pushout complements are unique |zz y U o P BO for M-morphisms (see Th. 4.26 in [3]), ∼ we can conclude that P BO = H. 4.2
Automatic deduction of migration rules from evolution steps
After having clarified how evolutions and migrations relate, we consider now a strategy to automatically deduce migration rules from evolution steps. Of course,
11
we are mostly interested in deducing match-complete and action-reflecting migration rules. The simplest case of migration rule deduction is to construct an isomorphic copy of an evolution rule. However, its application is usually not match-complete. Even worse, it might happen that the deduced rule cannot be applied to a given graph at all, since the gluing condition is not satisfied. Therefore, we present a more general deduction of migration rules taking the definition of matchcomplete and action-reflecting co-transformations into account. Since we will need to construct pullback complements, we recall this notion first. Definition 5 (Pullback complement). Let a : A → B and b : B → D be two morphisms, morphisms c : A → C and d : C → D are called a pullback complement of a and b if a and c are the pullback of b and d.
BO
b
a
A
/D O d
c
/C
Remark 2. In the category of sets and functions, a pullback can be constructed by A = {(x, y)|d(x) = b(y)} ⊆ C × D with morphisms a : A → B : (x, y) → y and c : A → C : (x, y) → x. In category AIGraphs, pullbacks can be constructed component-wise for nodes, edges, and attributes. If at least b or d is S −ref lecting, inheritance relations in A can be uniquely defined based on those in B and C (see also [7].) As shown in the proof of the following theorem, there is always a pullback complement of a and b if b is in M and thus is S-reflecting in AIGraphs. A pullback complement can be constructed by C being simply equal to A and mapped to D in the same way as A is mapped to D. Theorem 2 (Instance rule deduction). Given a co-span transformation tt : tp,tm tL m L −→ G T G =⇒ T H and a typing morphism tG : G → T G with pullback T L ←− tG tm G in a (weak) adhesive category: For each pullT G ←− of cospan T L −→ t m
l
t
tl
I L T L −→ T I, we obtain a matchback complement L −→ I −→ T I of L −→ complete, action-reflecting co-transformation and hence a co-span transformatp,tm tion from G −→ T G to H −→ T H based on tt : T G =⇒ T H. The construction is given by the following steps:
m
t
t
tm
G L T G ←− T L T L as pullback of G −→ 1. Construct G ←− L −→ tL tI tl l T L −→ T I 2. Construct a pullback complement L −→ I −→ T I of L −→ t t t r r I R TR T I ←− T R as pullback of I −→ 3. Construct I ←− R −→
Proof. Existence of a migration rule: Since category C is (weak) adhesive, pullbacks along M-morphisms exist. Thus, Steps 1 and 3 can always be performed. Furthermore, we have to check that a pullback complement exists, i.e. that Step tL tl T L −→ T I (with tl being in M), 2 can be performed. Given morphisms L −→ id
tl◦t
L L −→L T I by choosing we can always construct a pullback complement L −→ I = L: First, obviously, commutativity holds. Second, given Y with y1 : Y → T L , y2 : Y → L and tl ◦ y1 = tl ◦ tL ◦ y2 , there is a unique morphism y : Y → L with y2 = idL ◦ y and y1 = tL ◦ y, since tl is in M and therefore monomorphism.
12
Match-completion: Due to Step 1 of the construction, the migration is matchcomplete. Action-reflection: By the pullbacks constructed in Step 2 and Step 3, the migration is action-reflecting. Existence of a unique migration wrt. Step 2: L and the match m are uniquely determined by the pullback construction in Step 1. In Step 2, we choose a suitable pullback complement determining l and I. Finally, Step 3 uniquely determines r and R by a pullback construction. Since tm fulfills the co-span gluing condition by assumption (see Definition 2), this is also true for m (see Proposition 1 below). Example 3 (Deduction of model migrations). Considering the example metamodel evolution in Figure 5 an edge is deleted and a node with two edges are inserted. The deduction strategy in Theorem 2 determines a skeleton migration rule with a corresponding match, but does not yield a unique result: 1. Given graph G as in Figure 3, graph L is constructed as pullback object which determines all graph elements that are affected by the evolution. This result is unique (up to isomorphism) wrt. the evolution rule and its match to the graph to be migrated. 2. The next step is a pullback complement construction which is not unique in general. Actually various outcomes are possible. We discuss some interesting ones in the following: (a) Nothing is added to graph L, i.e. I = L, however tI : I → T I may not be surjective in this case. Non-surjectivity mean that the actions on type level are not completely reflected in the migration on the instance level which might be true if nothing is added. (b) One copy of each new type graph element is added to I. Consider e.g., the graph I in Figure 6: two copies of “InArr” are added here. If only one shall be added, one of these has to be selected non-deterministically. Thus, this construction seems to yield an incomplete result, although tI would become surjective i.e., reflecting fully the creation of new types. (c) I contains as many copies of T I as L contains of T L: This solution is very intuitive. It would yield graph I in Figure 6 as result. Of course, it is also action-reflecting. (d) Copies of new type graph elements are added as often as matches of anchor nodes are found in G: considering again graph I in Figure 6, this construction would yield two more “InArr” nodes with adjacent edges combining Transition (1) with Place (13) and Transition (15) with Place (3). While this solution is action-reflecting it is not very intuitive. 3. The final deduction step is a pullback construction yielding the right-hand side R of the migration rule. This construction performs the specified type graph deletions on all occurrences found in the first deduction step. The result is unique (up to isomorphism) wrt. the evolution rule and the intermediate pullback complement chosen. Example 4 (Co-span vs. span approach). As mentioned earlier we use “co-span” DPO transformations instead of “span” DPO transformations since they are
13
Fig. 7. Span migration and evolution rules
more suitable for migrations. The co-span approach has a positive effect when migration rules are deduced from evolution rules. Figure 7 shows an evolution rule and a well-typed migration rule formulated as spans. Consider the evolution rule as given, the left-hand-side of the migration rule has been derived by a pullback as discussed above. The dotted and dashed parts need to be added by rule deduction. The evolution rule presented in Fig. 7 does the first part for meta-model evolution step E2: it creates a new associated class “Token” and moves attribute “token” as attribute “number” to this class. Note that since a real move does not exist in graph transformations this basically means that the attribute arrow “token” is replaced by another attribute arrow “number” which has as source node the new associated class “Token”. A reasonable migration rule as presented in the figure does the same for all instances of these types. P B1 can be directly constructed. In the next step, pullback P B2 needs tI tr T I −→ T R. Here, we get a to be constructed as pullback complement of I −→ problem since the values “0” and “1” in graph I are not connected to any node anymore and therefore not displayed in the figure. To find the right values for attribute “number” in rule graph R we have to consider morphism l in addition. Compare Fig. 8 now, where the same evolution rule is formulated in the co-span
Fig. 8. Co-span migration and evolution rules
approach. This time P B1 has to be constructed as a suitable pullback comple-
14
ment. We do not run into any problem here since the values “0” and “1” are never unconnected. tp,tm
Proposition 1 (Deduction of boundary). Let tt : T G =⇒ T H be an evolup,m tl tr l r tion with rule tp = T L −→ T I ←− T R and t : G =⇒ H with p = L −→ I ←− R a migration wrt. tt deduced by the construction in Theorem 2. If tm satisfies the co-span gluing condition wrt. rule tp, then m satisfies the co-span gluing condition wrt. p. Proof. If tm satisfies the co-span gluing condition wrt. rule tp, there is a boundary tb : T B → T L of tm, i.e., there is a morphism tbr : T B → T R with tr ◦ tbr = tB b B −→ L be the pullback of tb and tL . In the diagram on the tl ◦ tb. Let T B ←− right (1) and (2) are pullbacks, hence (1+2) is also a pullback. Since t is actionreflecting, (3) is also a pullback. By astbr sumption there is a morphism tbr with (=) ) tr ◦ tbr = tl ◦ tb and since (1) and (2) T B / TI o / TL TR O O O O tr tl tb are pullbacks, we have tr ◦ tbr ◦ tB = t t tR t (1) (2) (3) B L I tI ◦ l ◦ b. Thus, there is a unique morb l phism br : B → R with r ◦ br = l ◦ b, /L /Io r 6R B according to the universal property of br pullback (3). The migration rule deduction presented in Theorem 2 yields migration rules which are specific to given instance graphs. Hence, for each instance graph this construction has to be repeated. Considering a set of graphs, this deduction strategy yields a migration rule schema. It is up to future work to analyze these schemes according to certain regularities. For example, it might be possible that a basic migration rule isomorphic to its evolution rule can be identified such that the union of any number of copies yields a migration rule of the given schema.
5
Related work
Co-evolution of structures has been considered in several areas of computer science such as database schemata, grammars, and meta-models [11,10,13,17]. Especially schema evolution has been a subject of research in the last decades. Recently, research activities have started to consider meta-model evolution and to investigate the transfer of schema evolution concepts to meta-model evolution (see e.g. [8]). In the following, we focus on meta-model evolution approaches. In the literature, meta-model differences are most basically given by change sets. These sets can be used to deduce evolution rules [19,14] or pre-defined operations [8]. Roughly spoken, a rule is deduced from a change set by throwing away unnecessary context and by abstracting from concrete values by variables (see [1]). If pre-defined operations are given as done in COPE [8] , they can be formally defined by single rules or rule sets. COPE [8] uses a meta-model independent representation to perform model migrations. In [16], the authors use pre-defined constructors that migrate models fully automatically. Type conformance of migrated models is mostly checked
15
during run time in the approaches we investigated, except [16] where the authors show that their automatically migrated model is always type conforming. While in COPE and [2,16], automatically generated migrators are available, the automatic deduction of migration strategies from evolution strategies is not considered in [17,19,2,14]. However, Flock [14] (and to a minor extent [17]) support at least the automatic copying of unchanged and slightly changed elements and the automatic unsetting of deleted features wrt. a given evolution rule leading to fairly compact migration scripts. To keep as much of the typing information as possible during evolutions, we consider an add-first-delete-then transformation approach which provides us with intermediate graphs that keep the original information and include new parts. Such intermediate graphs are able to retain typing information that is not changed during a meta-model evolution. If a corresponding migration reflects all actions of a given evolution and is match-complete wrt. to the given graph, we show that the resulting graph is uniquely typed over the resulting type graph. Thus, we do not have to check type conformance at run time as is done by nearly all approaches we considered, but can guarantee this property at design time, before migrations actually take place. A similar result can be found in [16], however our approach differs from that formalization: in [16], model migration is always fully determined, there are no possibilities to adapt migrators e.g. wrt. the reflection of new meta-model parts. We consider a general procedure to deduce migration rules from type graph evolutions and corresponding instance graphs leaving space for variants. Evolution examples in [16] are refactorings only, leaving the evaluation of other kinds of evolutions open. Furthermore, their representation of object structures is special in the sense that object slicing along class generalization relations is used to specify evolutions. Refactorings are specified as change-based requiring the specification of quite difficult folding and unfolding constructions. Our evolution specifications is more straight forward.
6
Conclusion
In this paper, we present a formal approach to model and meta-model coevolution based on graph transformations. Meta-model evolutions and corresponding model migrations are defined by co-transformations in (weak) adhesive categories. An example is given using the category of typed, attributed graphs with inheritance. Evolutions and migrations are specified by transformation rules that can be freely designed, i.e., there are no pre-defined operations to be used. We use a kind of transformations performing the addition of new structures first and delaying the deletion of structures not needed anymore. Our main result is concerned with the type conformance of instance graph migrations wrt. their type graph evolutions. While nearly all other co-evolution approaches delay the check of type conformance to run time, i.e., when model migrations are actually performed, we developed sufficient properties and a derivation strategy to identify type conforming migrations at design time.
16
In addition, we consider a formal framework for automatic deductions of instance graph migrations from given type graph evolutions. While deletion actions on type graphs have to be directly reflected on the instance level to preserve type conformance, the addition of new structures usually allows for variants of migrations. The addition of type graph elements leaves the modeler with the question if new type graph elements shall be used in the instance graph and if yes, how. This is reflected by the pullback complement construction which is not unique in general. We discussed several forms of graph adaptations. While the focus of this paper is on formalization of model and meta-model co-evolutions, the work flow of co-evolution processes as well as supporting tools are neglected here. Usually a meta-model evolution has taken place and numerous models have to be migrated accordingly. Thus, co-evolution usually does not take place synchronously as our formalization might suggest. However, interleaved evolution steps are also possible. In [12], an implementation based on the Eclipse Modeling Technology is presented where the addition of meta-model parts is performed first, models are migrated thereafter, and finally, unneeded meta-model parts are deleted. This work flow suits to our formalization in the sense that its meta-model evolutions can be directly formulated as co-span transformations. However, model migrations in [12] are less strictly typed since the intermediate meta-model is taken for typing whole migrations. It is straight forward to relax the typing of migrations being part of co- transformations as in this paper. Hence, they can be directly implemented by the approach in [12].
Acknowledgement Many thanks to Hartmut Ehrig for his valuable comments on a previous version of this paper and to Wendy McCaull for giving valuable language feedback.
References 1. Bisztray, D., Heckel, R., Ehrig, H.: Verification of architectural refactorings: Rule extraction and tool support. ECEASST 16 (2008) 2. Cicchetti, A., Ruscio, D.D., Eramo, R., Pierantonio, A.: Automating Co-evolution in Model-Driven Engineering. In: ECOC 2008. pp. 222–231. IEEE Computer Society (2008) 3. Ehrig, H., Ehrig, K., Prange, U., Taentzer, G.: Fundamentals of Algebraic Graph Transformation. Monographs in Theoretical Computer Science, Springer (2006) 4. Ehrig, H., Ehrig, K., Prange, U., Taentzer, G.: Fundamental Theory for Typed Attributed Graphs and Graph Transformation based on Adhesive HLR Categories. Fundam. Inform. 74(1), 31–61 (2006) 5. Ehrig, H., Hermann, F., Prange, U.: Cospan DPO Approach: An Alternative for DPO Graph Transformation. EATCS Bulletin 98, 139–149 (2009) 6. Habel, A., Pennemann, K.H.: Correctness of high-level transformation systems relative to nested conditions. Mathematical Structures in Computer Science 19(2), 245–296 (2009)
17 7. Hermann, F., Ehrig, H., Ermel, C.: Transformation of Type Graphs with Inheritance for Ensuring Security in E-Government Networks. In: FASE 2009. LNCS, vol. 5503, pp. 325–339. Springer (2009), long version available as TR 2008-07 at TU Berlin, Germany 8. Herrmannsdoerfer, M., Benz, S., J¨ urgens, E.: COPE - Automating Coupled Evolution of Metamodels and Models. In: ECOOP 2009. LNCS, vol. 5653, pp. 52–76. Springer (2009) 9. Lack, S., Sobocinski, P.: Adhesive Categories. In: Walukiewicz, I. (ed.) FoSSaCS. LNCS, vol. 2987, pp. 273–288 (2004) 10. L¨ ammel, R.: Grammar Adaptation. In: FME. pp. 550–570 (2001) 11. Li, X.: A Survey of Schema Evolution in Object-Oriented Databases. In: TOOLS. pp. 362–371. IEEE Computer Society (1999) 12. Mantz, F., Jurack, S., Taentzer, G.: Graph Transformation Concepts for MetaModel Evolution Guaranteeing Permanent Type conformance Throughout Model Migration. In: AGTIVE. LNCS, vol. 7233. Springer (2012) 13. Pizka, M., Juergens, E.: Automating Language Evolution. In: TASE ’07: Proceedings of the First Joint IEEE/IFIP Symposium on Theoretical Aspects of Software Engineering. pp. 305–315. IEEE Computer Society, Washington, DC, USA (2007) 14. Rose, L.M., Kolovos, D.S., Paige, R.F., Polack, F.A.C.: Model Migration with Epsilon Flock. In: Theory and Practice of Model Transformations, ICMT 2010, Spain. LNCS, vol. 6142, pp. 184–198. Springer (2010) 15. Rutle, A., Rossini, A., Lamo, Y., Wolter, U.: A formal approach to the specification and transformation of constraints in MDE. JLAP 81/4, 422–457 (2012) 16. Schulz, C., L¨ owe, M., K¨ onig, H.: A categorical framework for the transformation of object-oriented systems: Models and data. J. Symb. Comput. 46(3) (2011) 17. Sprinkle, J., Karsai, G.: A domain-specific visual language for domain model evolution. J. Vis. Lang. Comput. 15(3-4), 291–307 (2004) 18. Sprinkle, J., Rumpe, B., Vangheluwe, H., Karsai, G.: Metamodelling - State of the Art and Research Challenges. In: Model-Based Engineering of Embedded RealTime Systems. LNCS, vol. 6100, pp. 57–76. Springer (2010) 19. Wachsmuth, G.: Metamodel adaptation and model co-adaptation. In: ECOOP 2007. LNCS, vol. 4609, pp. 600–624. Springer (2007)
