GTS Families for the Flexible Composition of Graph Transformation Systems
 870 Downloads
Abstract
Morphisms between graphtransformation systems (GTSs) have been successfully used for the refinement, reuse, and composition of GTSs. All these uses share a fundamental problem: to be able to define a morphism, source and target GTSs need to be quite similar in their structure (in terms of both the type graphs and the set of rules and their respective structures). This limits the applicability of these approaches by excluding a wide range of mappings that would intuitively be accepted as meaningful, but that cannot be captured formally as a morphism. Some researchers have attempted to introduce some flexibility, but these attempts either focus only on the type graphs (e.g., Kleisli morphisms between type graphs) or only support specific forms of deviation (e.g., supporting subtyping in type graphs through clan morphisms). In this work, we introduce the notion of GTS families, which provide a general mechanism for explicitly expressing the amount of acceptable adaptability of the involved GTSs so that the intended morphisms can be defined. On this basis, we demonstrate how GTS families that are extension preserving can be used to enable flexible GTS amalgamation.
Keywords
Transformation Rule Graph Transformation Type Graph Extension Preserve Output Queue1 Introduction
Graph transformation systems (GTSs) were proposed in the late seventies as a formal technique for the rulebased specification of the dynamic behaviour of systems [1]. Since then, GTSs have been used in different contexts in computer science, including the formalisation of systems, programming languages and modeldriven engineering.
In the many contexts in which GTSs have been used, a key ingredient for exploiting their power is that of GTS morphisms. GTS morphisms have been used for different purposes in system specification, for instance, to characterise the relationship between a system and views of it [2], for expressing refinements [3, 4], or for modelling import and export interfaces of modules [5]. Recent uses of GTSs in the context of ModelDriven Engineering (MDE) have gone one step further, proposing practical uses of different forms of parametric GTSs for reusing model transformations, and reusing and composing domain specific language (DSL) definitions. In [6], de Lara and Guerra proposed the use of transformation templates, typed by a graph, that they call concept, which can then be instantiated by binding the concept to a concrete graph. Durán et al. proposed in [7, 8] what they call parameterised GTSs, where the parameter is not just a type graph, but a complete GTS, and where composition of GTSs is based on a GTS amalgamation construction. In the same way concepts gather the structural requirements, the set of rules of parameter GTSs are behavioural requirements over the concrete GTSs used in the instantiation. In each of these cases, using GTS morphisms enables useful syntactic or semantic guarantees to be given. For example, in [6] the use of morphisms means that transformations can be guaranteed to be syntactically reusable. In the case of [8], the use of suitable morphisms enables guarantees on behaviour protection of amalgamated GTSs.
For reuse and composition, the main difficulty is the flexibility of the mechanisms available. In specific domains, ad hoc definitions of GTS morphisms have been proposed. For example, an alternative notion of refinement relation is given for transactional graph transformation systems in [9], where a graph typing mechanism induces a distinction between stable and unstable graph items and where implementation morphisms map single productions to whole transactions so that morphisms define simulations. Taentzer [10] uses a subset of UML extended by reconfiguration and import/export view facilities, represented as embedding morphisms, to propose a formal framework for visual modeling of distributed object systems. Component composition is defined by only allowing embedding morphisms between import and export rules where each two rules connected by an embedding morphism are named equally. These specialised solutions do not easily extend to the general setting. The use of GTSs in MDE introduces even more challenges, as we need to consider more complex graphs including attributes and nodetype inheritance [11].
The need for a mechanism for relating different GTSs, or their type graphs, that is more flexible than direct morphisms—to broaden opportunities for GTS reuse—has been recognised before: In the case of models, represented as graphs, this has been resolved more or less pragmatically by supporting a specific, fixed set of adaptations to be applied prior to applying the morphism (see, e.g., [6, 11, 12, 13]). For example, Diskin et al. [12] propose using Kleisli categories for relating models. De Lara and Guerra extended their work on concepts in [13] by using adapters to allow heterogeneities between the concept and the concrete graph. Each of these works “hard wires” a specific set of flexibilities.
To support complete GTSs, rules must also be related in a flexible manner. In [4, 14], GroßeRhode et al. introduce temporal and spatial refinement relations. In a spatial refinement, each rule is refined by an amalgamation (i.e., a parallel composition with sharing) of rules, while in a temporal refinement it is refined by a sequential composition. Engels et al. [5] present a framework for classifying and systematically defining GTS morphisms. Different types of morphisms are characterised by their relationship between the behaviours of source and target GTSs. For instance, refinements are a case of behaviourpreserving morphisms, while views are a case of behaviourreflecting morphisms. Durán et al. [8] similarly introduce different behaviouraware GTS morphisms.
These solutions are, however, far from satisfactory. Even though the introduction of derived attributes and links as in [12] or [13], and the behavioural relations provided for GTS morphisms as in [8] improve the chances of defining the required morphisms, structural mismatch remains a problem. Often even where there is an intuitive match, no morphism can be established. This substantially limits the reuse potential of these approaches. In many cases, a simple restructuring of the GTSs involved could easily allow a valid mapping to be established. However, there is currently no support for capturing such restructurings, and in particular for capturing exactly the set of restructurings the designer of a GTS would consider valid and meaningful.
In this work, we propose the use of GTS transformers to refactor GTSs with the goal of resolving the structural mismatches between source and target GTSs so that GTS morphisms can be defined. In fact, GTS transformers may be seen as refactoring mechanisms, which provide a general setting for defining adaptations. GTS transformers are functions, and can successively be applied to our source GTS to find the one on which the morphism can be defined. To systematise this, we introduce the notion of GTS families. Given a set of transformers T, the Tfamily of a GTS \( GTS _{0}\) is the set of GTSs reachable from \( GTS _{0}\) using the transformers in T. The problem of defining a mapping morphism between a GTS \( GTS _{0}\) and a target GTS \( GTS _{1}\) then amounts to finding a GTS in the family of \( GTS _{0}\) from which the morphism can be defined. This way, the problem becomes a modelbased search problem [15].
Of course, any mechanisms enabling more flexibility must balance this against the required level of control so that suitable semantic properties can be guaranteed. We provide different transformers and prove that they preserve extensions [16] between GTSs. As a result, we show how these transformers can be used to enable flexible composition of GTSs.
The remainder of this paper is structured as follows. In Sect. 2, we introduce a running example and motivate the limitations of GTS morphisms and the need for more flexibility. After providing some formal background on typed attributed graphs, GTSs, and their morphisms in Sect. 3, Sect. 4 introduces the notions of GTS transformers and GTS families as well as three example GTS transformers. In Sect. 4.3, we show that these transformers are extension preserving and can, thus, be used to compose GTSs using the mechanism from [16]. We wrap up in Sect. 5 with some conclusions and lines of future research.
2 Running Example
For this to work, we need to establish a GTS morphism between the Server GTS (the parameter) and the PLS GTS. Intuitively, the PLS GTS might be seen as a concrete interpretation of the Server GTS—e.g., polishing of parts can be seen as particular case of the server processing. A morphism between the two GTSs would be the formal expression of this. Let us first focus on the type graphs. At first sight, it may seem quite reasonable to define a binding between \({ TG }_{ Server }\) and \({ TG }_{ PLS }\) by mapping Open image in new window into Polisher, and Queue into Container,^{2} with the in and out associations going to the corresponding ones in the PLS system type graph. However, in \({ TG }_{ PLS }\) input and output “queues” are represented by two different types: Tray and Conveyor, respectively. As a result, we cannot establish a valid morphism. Whether source and target queues are of the same type is not actually relevant to our specification of Open image in new window nor to the definition of tracking. We would like to be able to express the intuition that this particular mapping should be considered valid. Even where we can establish a morphism between the type graphs, there may still be problems establishing morphisms between the rule sets.
3 Preliminaries on GTSs, Clans, and Clan Morphisms
We focus on the double pushout (DPO) approach to graph transformation [3]. In this section, we introduce some of the basic definitions concerning typed graphs and the algebraic approaches to the rewriting of typed graphs, and provide background definitions underpinning our discussion throughout this paper. The notation and most of the definitions in this section follow very closely those in, e.g., [3, 8, 13, 17].
3.1 Graph Transformation Systems
Given some category of graphs and graph morphisms Graph, and given a distinguished graph \({ TG }\), called type graph, a \({ TG }\)typed graph \((G,{g_G})\), or simply typed graph if \({ TG }\) is known, consists of a graph G and a typing homomorphism \(g_G:G\rightarrow TG\) associating with each vertex and edge of G its type in \({ TG }\). To enhance readability, we will use simply \(g_G\) to denote a typed graph \((G,g_G)\), and when the typing morphism \(g_G\) can be considered implicit, we will often refer to a typed graph \((G,g_G)\) just as G. A \({ TG }\)typed graph morphism between \({ TG }\)typed graphs \((G_i,{g_i:G_i\rightarrow TG})\), with \(i=1,2\), denoted \(f\!:(G_1,g_1)\rightarrow (G_2,g_2)\), is a graph morphism \(f\!:G_1\rightarrow G_2\) which preserves types; that is, \(g_2\circ f=g_1\).
A graph transformation rule^{3} p is of the form \(L \mathop {\leftarrow }\limits ^{l}K\mathop {\rightarrow }\limits ^{r}R\) with graphs L, K, and R, called, resp., lefthand side, interface, and righthand side, and some kind of monomorphisms (typically inclusions) l and r.
A graph transformation system (GTS) over a type graph \({ TG }\) is a triple \(({ TG },P,\pi )\) where P is a set of rule names and \(\pi \) is a function mapping each rule name p into a rule \(L\mathop {\leftarrow }\limits ^{l}K\mathop {\rightarrow }\limits ^{r}R\) typed over \({ TG }\).
Since we are interested in relating GTSs over different type graphs, we need to move graphs and graph morphisms along morphisms. Assuming \(\mathbf{Graph }_{{ TG }}\) the category of \({ TG }\)typed graphs and \({ TG }\)typed graph morphisms, a graph morphism \({f\!:{ TG }\rightarrow { TG }'}\) induces forward and backward retyping functors \(f^{>}\!:\mathbf{Graph }_{{ TG }}\rightarrow \mathbf{Graph }_{{ TG }'}\) and \({f^{<}\!:\mathbf{Graph }_{{ TG }'}\!\rightarrow \!\mathbf{Graph }_{{ TG }}}\). Since, as said above, we refer to a \({ TG }\)typed graph \(G \rightarrow { TG }\) just by its typed graph G, leaving \({ TG }\) implicit, given a morphism \({f\!:{ TG }\rightarrow { TG }'}\), we may refer to the corresponding \({ TG }'\)typed graph by \({f^{>}(G)}\). Since we can retype graphs and graph morphisms, we can retype rules. Given a rule p over a type graph \({ TG }\) and a graph morphism \({f\!:{ TG }\rightarrow { TG }'}\), we will write things like \(f^{<}(p)\) and \(f^{>}(p)\) denoting, respectively, the backward and forward retyping of rule p.
3.2 Morphisms Between Graph Transformation Systems
Although the mechanisms presented in the following sections may be applicable to most notions of GTS morphisms defined in the literature, to simplify the presentation we will focus on a specific type of rule morphism and GTS morphism. We begin with rule morphisms, relating two graphtransformation rules.^{4}
Definition 1
We are now ready to introduce GTS morphisms.^{5}
Definition 2
Given GTSs \( GTS _{i}={({ TG }_i,P_i,\pi _i)}\), for \(i={0,1}\), a GTS morphism \(f\!: GTS _{0}\!\rightarrow \! GTS _{1}\), with \(f={(f_{{ TG }},f_P,f_r)}\), is given by a morphism \(f_{{ TG }}\!:{ TG }_0\!\rightarrow \!{ TG }_1\), a surjective mapping \(f_P\!:{P_1\!\rightarrow \! P_0}\) between the sets of rule names, and a family of rule morphisms \(f_r = \{f^p\!:f^>_{TG}(\pi _0(f_P(p)))\rightarrow \pi _1(p)\}_{p\in P_1}\).
A special kind of GTS morphism is a GTS extension, which is essentially an inclusion such that everything being added to the rules of the extended GTS is typed by elements also added to the type graph.
Definition 3
(GTS Extension [16]). Given GTSs \( GTS _{i}={({ TG }_i,P_i,\pi _i)}\), for \({i=0,1}\), a GTS morphism \({f\!: GTS _{0}\rightarrow GTS _{1}}\), with \(f={(f_{{ TG }},f_P,f_r)}\), is an extension morphism if \(f_{{ TG }}\) is a monomorphism and for each \(p\in P_1\), \(\pi _0(f_P(p)) = f^{<}_{{ TG }}(\pi _1(p))\).
3.3 Typed Attributed Graphs and Clan Morphisms
Our underlying graphs are attributed graphs typed over attributed type graphs with inheritance [3, 11]. In these graphs, attributes are represented as edges between graph nodes and data nodes (captured by the notion of Egraphs in [3]). We use symbolic graphs [19, 20] to enrich graphs with a set \(\varPhi \) of formulas over a signature \(\varSigma =(S,\varOmega )\), with S a set of sorts and \(\varOmega \) a set of operations. We assume that each formula is an equality between a variable and its value (grounded symbolic graphs in [19]). For simplicity, we assume attributed graphs on the same signature and omit a treatment of cardinalities and composition relations, which could be given as constraints as discussed in [21]. We refer the interested reader to [19, 20] for a more general presentation of symbolic attributed graphs.
An attributed graph \( ATG =({ TG },\varPhi )\) may be used as a type graph. As for any type of graph, a typed attributed graph (AG, t) over an attributed type graph \( ATG \) consists of an attributed graph AG together with an attributed morphism \(t:AG\rightarrow ATG \). A typed attributed graph morphism \(f:(AG_1,t_1)\rightarrow (AG_2,t_2)\) is an attributed graph morphism \(f:AG_1\rightarrow AG_2\) such that \(t_2\circ f=t_1\).
To deal with objectoriented systems we need some additional machinery. We follow [11] in defining attributed type graphs with inheritance.
Definition 4
An attributed type graph with inheritance \( ATGI =( ATG ,I,Ab)\) consists of an attributed type graph \( ATG =({ TG },\varPhi )\), with an Egraph \({ TG }=(V, E, A, D, s^E, t^E, s^A, t^A)\), a set \(I\subseteq V\times V\) of inheritance relations, and a set \(Ab\subseteq V\) of abstract nodes.
The typing of an object diagram with respect to a class diagram is typically represented as a clan morphism [11]. Intuitively, a clan morphism \(f:AG\rightarrow ATGI \) from an attributed graph AG to an attributed type graph with inheritance \( ATGI \) is an attributed graph morphism that takes into account the inheritance relation and abstraction definitions of the target \( ATGI \).
Definition 5
 1.
\(\forall e \in E_{{ TG }_1}, f_V(s^{E}_{{ TG }_1}(e))\in clan(s^{E}_{{ TG }_2}(f_E(e))) \ and ~\qquad f_V(t^{E}_{{ TG }_1}(e))\in clan(t^{E}_{{ TG }_2}(f_E(e)))\), and
 2.
\(\forall a \in A_{{ TG }_1}, f_A(s^{A}_{{ TG }_1}(a))\in clan(s^{A}_{{ TG }_2}(f_A(a))) \ and ~\qquad f_A(t^{A}_{{ TG }_1}(a)) = t^{A}_{{ TG }_2}(f_A(a))\).
Definition 6
 1.
preserves the inheritance relation, i.e., if \((a,b)\in I_1\) then \((f_V(a),f_V(b))\in I^*_2\),
 2.
reflects subtyping, that is, for each \((a,b)\in I_2^*\) with some \(a'\in V_1\) such that \(f_V(a')=a\), there must be a \(b'\in V_1\) such that \(f_V(b')=b\) and \((a',b')\in I^*_1\), where \(V_1\) is the node set of \( ATG _1\), and
 3.
preserves the abstraction definitions, that is, \(u \in Ab_1\Leftrightarrow f_D(u)\in Ab_2\).
Example 1
The mapping in Sect. 2 between \({ TG }_{ Server }\) and \({ TG }_{ PLS }\) does not satisfy the conditions to be part of a clan morphism. Specifically, the mapping for the in association fails condition 1 in Definition 5: \(f_V(t^{E}_{ Server }(\textsf {in})) = \textsf {Container} \not \in clan(t^{E}_{ PLS }(f_E(\textsf {in}))) = \{ \textsf {Tray} \}\).
4 GTS Transformers and Families
Intuitively, a GTS family is a set of GTSs inductively defined from a source GTS \( GTS _{0}\), capturing exactly the kind of flexibility we would like to permit when mapping \( GTS _{0}\) to another GTS \( GTS _{1}\). Given a set of transformers T, that model the different alterations that may be applied on GTSs, we denote by \([ GTS _{0}]_{T}\) the family of \( GTS _{0}\) using T. Mappings are then formally defined by selecting one GTS from the GTS family of \( GTS _{0}\), written \([ GTS _{0}]_{T} \leadsto GTS _{0}'\), and establishing a morphism between \( GTS _{0}'\) and \( GTS _{1}\). We first introduce the notion of GTS transformers, before using them to formally define GTS families. We then show how extension preserving transformers can be used to enable the flexible composition of GTSs and how individual members of a GTS family can be identified based on a given target GTS for a mapping.
4.1 GTS Transformers
GTS transformers, and the GTS families we generate with them, generalise the idea of adapters over transformations (also called adaptations in [13, 22, 23]). We start by defining GTS transformers as transformations between GTSs.^{6}
Definition 7
 \(t_{ { TG } }\)

takes GTSs to type graphs;
 \(t_{P}\)

takes GTSs to sets of rule names;
 \(t_{\pi }\)

takes GTSs to functions mapping rule names to rules.
Note that while the three component functions are defined to range over the entire GTS, they each only transform one aspect of the GTS. For example, \(t_{ { TG } }\) will only transform the type graph of the given GTS. However, we define them to range over the entire GTS so that they can ensure consistency of the result.
Remark 1
By definition, given a valid GTS as input, a welldefined GTS transformer will always produce a valid GTS as output.
To make this definition more concrete, we now introduce three examples of transformers, namely \( t _{ IntroSC }\), \( t _{ MvAssoc }\) and \( t _{ InhUnfld }\), which, respectively, add subclasses in the inheritance hierarchy, move associations in its type graph down in the inheritance hierarchy, and specialise rules to particular subclasses.
Definition 8
The \( t _{ IntroSC }\) transformer modifies the type graph of a GTS by introducing a subclass to a class. It nondeterministically chooses a class from the type graph of the original GTS and adds a subclass with no attributes nor associations. All other classes, attributes, and associations are maintained. The set of rules is not changed.
Example 2
By repeatedly applying \( t _{ IntroSC }\) to the Server GTS in Fig. 3 we could obtain, e.g., a GTS Server v1 with the type graph shown in Fig. 5. The set of rules in the new GTS are identical to the rules in the original GTS.
Definition 9
 1.
Nondeterministically picks a class \(C \in TG_0\) that has a number of subclasses \(SC_i \in TG_0\), \(i = {1,\ldots ,n}\);
 2.
Nondeterministically picks a rule name \(p \in P_0\) s.t. \(\pi _0(p)\) contains objects that are typed by C;
 3.
Nondeterministically picks one subclass of C for every free object in \(\pi _0 (p)\) typed by C (different subclasses may be picked for different objects);
 4.
Generates a new rule \(\pi _1 (p)\) using the chosen subclasses to type the corresponding objects;
 5.
Copies all other rules as they are.
Example 3
Given the Server v1 GTS resulting from the application of the \( t _{ IntroSC }\) transformer as in Example 2, the application of the \( t _{ InhUnfld }\) transformer on it may result in the GTS Server v2 with the same type graph and a rule as in Fig. 4b. All other rules remain as in the original GTS.
Definition 10
 1.
Nondeterministically picks a class C.
 2.
Nondeterministically picks an association assoc that ends in C.
 3.
Nondeterministically picks a set SC of subclasses of C. At least every subclass S of C for which there is a rule in \(\pi _0\) where assoc refers to an object typed as S will be included in SC.
 4.
If C and assoc are such that there are no rules that use assoc to refer to an object typed as C, then assoc is removed from the type graph, and a new replica of assoc with the same source as the original is created and defined to point to each \(S \in SC\).
If the type graph modification is not possible, because the condition in Step 4 fails, \( t _{ MvAssoc }\) returns the original GTS.
The condition in Step 4 as well as the specific construction of the set SC are required to ensure that \( t _{ MvAssoc }\) produces a valid and welltyped GTS.
Example 4
Repeatedly applying \( t _{ MvAssoc }\) to the Server v2 GTS produced in Example 3, may result in a GTS Server v3 with the type graph in Fig. 4a and the rules as those of Server v2 GTS.
The three introduced transformers are just a sample of the kind of transformations we can define on GTSs. For our running example, we have used these transformers to reflect our intuition that the specific types of input and output queues are not important for the behaviour we want to abstract in the Server GTS. As we have mentioned at the beginning of this section, the mismatches may be both in the structure or in the transformation rules, and therefore more sophisticated transformers operating on the type graph and on the rules may be necessary in other cases. In the next subsection we introduce GTS families as a way of packaging the transformers representing our intuition about the behaviour we want to capture.
4.2 GTS Families
Given a set of GTS transformers, new GTSs can be derived from a GTS.
Definition 11
Given a GTS \( GTS _{0}\) and a GTS transformer t, a singlestep GTS derivation \( GTS _{0} \Rightarrow _t GTS _{1}\) is induced iff \( GTS _{1}=t( GTS _{0})\). Given a set \(T = \left\{ t_i  i = 1, \ldots , n\right\} \) of GTS transformers, a GTS derivation of \( GTS _{0}\) over T (\( GTS _{0}\Rightarrow _T^* GTS _{m}\)) is given by a, possibly empty, sequence of singlestep derivations \( GTS _{j}\Rightarrow _{t_j} GTS _{j+1}\), \(j=0,\ldots ,m1\), \(t_j\in T\).
Example 5
After the application of transformers \( t _{ IntroSC }\), \( t _{ InhUnfld }\), and \( t _{ MvAssoc }\) as in Examples. 2–4, the morphism between GTSs Server v3 and PLS can now be defined, as sketched in Fig. 6.
We call the (possibly infinite) set of all GTSs derivable from \( GTS _{0}\) over a set of transformers T the Tfamily of \( GTS _{0}\).
Definition 12
Given a set of GTS transformers \(T=\left\{ t_ii=1,\ldots ,n\right\} \), and a GTS \( GTS _{0}\), the Tfamily of \( GTS _{0}\), denoted by \(\left[ GTS _{0}\right] _{T}\), is the (possibly infinite) reflexivetransitive closure of GTS derivations of \( GTS _{0}\) over T: \( GTS _{0}'\in \left[ GTS _{0}\right] _{T}\Leftrightarrow GTS _{0} \Rightarrow _{T}^* GTS _{0}'\).
We will write \(\left[ GTS _{0}\right] _{T} \leadsto GTS _{0}'\) to denote the selection of some \( GTS _{0}'\) from the GTSs in \(\left[ GTS _{0}\right] _{T}\). Note that \( GTS _{0} \in \left[ GTS _{0}\right] _{T}\).
The GTS transformers defined above, nondeterministically select elements of the type graph or rules to be modified. In analogy to graphtransformation rules, we allow transformer applications to be guided by providing a (partial) match for these elements. We will refer to the combination of a transformer and a complete match for each of the elements it would otherwise select nondeterministically as a specific application of a transformer.
Example 6
Consider the GTS Server v1 in Example 2. It results from the repeated application of the \( t _{ IntroSC }\) transformer (Definition 9). Specifically, given the Server GTS we may invoke the application of \( t _{ IntroSC }\) on class Queue, introducing subclass Queue1, followed again by its application on class Queue to introduce the subclass Queue2.
4.3 Extension Preserving Transformers and GTS Amalgamation
An interesting case, with direct application to parameterized GTSs, is the case of extensions (see Definition 3). Parametrization of GTSs establishes an inclusion between the parameter GTS (\( GTS _{0}\)) and the full, parametrized GTS (\( GTS _{1}\))—for example, see [8]. Typically, these inclusions are extensions.
To improve the possibilities of instantiating a parameterized GTS, we would like to be able to consider as parameter GTS any of the GTSs we can reach using a given set of transformers. In other words, we would like to be able to consider as parameter, not a single GTS, but its entire family. To make this safe, we need to ensure that for any path of transformers \( GTS _{0} \Rightarrow _{T}^{*} GTS _{0}'\) we can find a corresponding path \( GTS _{1} \Rightarrow _{T}^* GTS _{1}'\) such that the extension \( GTS _{0}\hookrightarrow GTS _{1}\) leads to the extension \( GTS _{0}'\hookrightarrow GTS _{1}'\); that is, a new parametrized \( GTS _{}\) preserving the extension. The easiest way of finding such a corresponding path is by constructing it from the same transformer applications in both cases. Transformers for which this can be done, we will call extensionpreserving transformers.
Definition 13
Note that it is enough to prove that each individual transformer is extension preserving for any combination of these transformers to be extension preserving, too. In particular, to be extension preserving, a transformer needs to be applicable both on \( GTS _{0}\) and on \( GTS _{1}\) without changes.
Proposition 1
The \( t _{ IntroSC }\) transformer preserves extensions.
Proof
Given GTSs \( GTS _{i} = \left( { TG }_i, P_i, \pi _i\right) \), with \(i=0,1\), and \(\iota =(\iota _{{ TG }},\iota _{P}, \iota _{r}): GTS _{0}\hookrightarrow GTS _{1}\) an inclusion morphism, the first observation is that if the \( t _{ IntroSC }\) transformer is applicable to \( GTS _{0}\), then it can also be applied to \( GTS _{1}\) in exactly the same way. All classes in \({ TG }_0\) are in \(TG_1\), and specifically the class C to which the new subclass is added. Assume that the application of \( t _{ IntroSC }\) on \( GTS _{0}\) results in a new GTS \( GTS _{0}' = \left( { TG }_0', P_0, \pi _0\right) \), with rules as in \( GTS _{0}\) and a type graph \(TG_0'\) as \(TG_0\) but with a new class \(C'\) added, and declared subclass of C. Applying \( t _{ IntroSC }\) to \( GTS _{1}\) results in the introduction of the new class \(C''\) as a subclass of \(\iota _{{ TG }}(C)\), with no attributes or links. This produces a new GTS \( GTS _{1}' = \left( { TG }_1', P_1, \pi _1\right) \), with the same rules as in \( GTS _{1}\). The inclusion morphism \(\iota '=(\iota '_{{ TG }},\iota '_{P}, \iota '_{r}): GTS _{0}'\hookrightarrow GTS _{1}'\) can trivially be defined by defining \(\iota '_{{ TG }}\) by extending \(\iota _{{ TG }}\) for the new class and subclass relation, mapping \(C'\) to \(C''\), with the same components for the rules. Notice that if \(\iota _{{ TG }}\) is an attribute type graph morphism, then \(\iota '_{{ TG }}\) is as well, since it preserves the inheritance relation, reflects subtyping, and preserves the abstraction definitions. Since rules are not changed, if \(\iota \) is an extension, then \(\iota '\) is also an extension.
Proposition 2
The \( t _{ InhUnfld }\) transformer preserves extensions.
Proof
Let GTSs \( GTS _{0}\) and \( GTS _{1}\) and inclusion GTS morphism \(\iota : GTS _{0}\hookrightarrow GTS _{1}\) as in Proposition 1, and let us assume it is an extension. Since the type graph is not changed, if the transformer is applicable on \( GTS _{0}\), it is obviously applicable on \( GTS _{1}\) for same class C, rule p and subclasses of C. We can define the inclusion morphism \(\iota '=(\iota '_{{ TG }},\iota '_{P},\iota '_{r}): GTS _{0}'\hookrightarrow GTS _{1}'\) by taking the same type graph morphism and morphisms for nonmodified rules. Since the transformer replaces rules \(\pi _0(p)\) and \(\pi _1(p)\) with rules \(\pi '_0(p)\) and \(\pi '_1(p)\), respectively in \( GTS _{0}\) and \( GTS _{1}\), with these new rules generated in exactly the same way, given \(\iota ^p\! : \iota ^>_{{ TG }}(\pi _0(\iota _P(p))) \rightarrow \pi _1(p)\) we have \(\iota '^p\! : \iota ^>_{{ TG }}(\pi _0'(\iota _P'(p))) \rightarrow \pi _1'(p)\). Since \(\iota \) is an extension, to have that \(\iota '\) is also an extension we just need to check that \(\pi '_0(f'_P(p))=f^{<}_{{ TG }}(\pi '_1(p))\). But this is the case, since the transformer is exactly making the same changes.
Proposition 3
The \( t _{ MvAssoc }\) transformer preserves extensions.
Proof
Let GTSs \( GTS _{0}\) and \( GTS _{1}\) and inclusion GTS morphism \(\iota : GTS _{0}\hookrightarrow GTS _{1}\) as in Proposition 1. The transformer just moves an association assoc from class C to one or more of its subclasses, requiring that there is no rule in the source GTS using assoc on instances of C. Assuming \(\iota \) is an extension, then, if \( t _{ MvAssoc }\) is applicable on \( GTS _{0}\) for some C, some subclass(es) of C and rule p, there cannot be in \( GTS _{1}\) a new rule, or an extension of a rule in \( GTS _{0}\), with such a link (to C or any of its subclasses), and therefore the same application of the transformer is possible on \( GTS _{1}\). Since the transformer is changing associations consistently in \({ TG }_0\) and \({ TG }_1\), the definition of \(\iota '_{{ TG }}\) follows quite closely that of \(\iota _{{ TG }}\). Rules are left unchanged, so the definitions of \(\iota '_{P}\) and \(\iota '_{r}\) are as those in \(\iota \). Thus, we can conclude that \(\iota '\) is also an extension.
In other words, we explicitly encode the variability we find acceptable by extending the parameter GTS \( GTS _{0}\) into a GTS family \(\left[ GTS _{0}\right] _{T}\), providing transformers \( t _{ IntroSC }, t _{ InhUnfld }\), and \( t _{ MvAssoc }\) in T. By using these transformers, we can derive a GTS \( GTS _{0}'\) (see Fig. 4) for which a GTS morphism f can be established to the PLS described in \( GTS _{2}\). Because all the transformers in T are extensionpreserving, we can derive a corresponding \( GTS _{1}'\) and the extension \(g': GTS _{0}' \hookrightarrow GTS _{1}'\). With these, we can finally apply the amalgamation scheme from [16] to produce the composed GTS \(\widehat{ GTS _{}}\).
4.4 Finding GTSFamily Members
Finding the appropriate representative of a GTS family for a given composition problem is not trivial. Essentially, this requires searching through the space of GTSs spanned by the GTS family, looking for a GTS with the right structure, if any exists. Searchbased problems have long been the subject of intense research interest [15]. More recently, there have been proposals for tools solving search problems in an MDE context [25, 26, 27]. Of particular interest in the context of GTS families is the work on MoMOT by Fleck et al. [27]. Here, new candidate solutions are found by applying a sequence of transformations to an initial model (e.g., a GTS). The search is guided by appropriate fitness criteria (e.g., the number of matching elements that could be used to construct a suitable morphism). Their approach keeps track of the transformation sequence at all time and thus guarantees that it will only find solutions for which there is a transformation sequence—a key criteria in finding representatives of GTS families.
Based on similar ideas, we have developed a basic automated search algorithm in Maude [28]. This prototype demonstrates that automated search of suitable GTSs in a GTS family is possible, but the prototype still suffers from inefficiencies. As part of our future work, we are exploring improving the implementation based on MoMOT or similar tools.
5 Conclusions
In this paper, we have presented GTS families as a mechanism for encoding controlled flexibility for morphisms between GTSs. This is achieved by extending a GTS \( GTS _{0}\) to a set of GTSs that can be derived from \( GTS _{0}\) given a set of GTS transformers T. This set is called the GTS Tfamily of \( GTS _{0}\) and is taken to encode the full intent of what is expected to be preserved by any morphism from \( GTS _{0}\). Then a direct morphism between \( GTS _{0}\) and \( GTS _{1}\) is replaced by selecting a suitable representative from the GTS family and defining the morphism from that representative. Thus, instead of direct morphisms \( GTS _{0} \rightarrow GTS _{1}\) we will use the construction \(\left[ GTS _{0}\right] _{T} \leadsto GTS _{0}' \rightarrow GTS _{1}\).
In addition to providing an explicit design mechanism for transformation developers, GTS families as a formal concept also open up a new research agenda: rather than relying on the pragmatic approaches taken to the definition of valid adaptations so far, we can now begin to study the fundamental properties of different types of GTS transformers, identifying different classes of GTS families that can be most appropriately used in different scenarios (e.g., are there easily checked conditions that will guarantee extension preservation?). In this paper, we have shown how extensionpreserving transformers can be used to construct GTS families that enable flexible GTS amalgamation. As part of our future work, we plan to study the properties required of GTS transformers to allow flexible reuse of transformations, extending the work by de Lara et al. to semantic transformation reuse.
Footnotes
 1.
We use the hollowarrow notation from UML to denote inheritance relationships.
 2.
Notice that although we use Queue to name the device in which input and output elements are placed, no specific order is assumed on its elements in the server GTS.
 3.
As a simplification, we do not consider application conditions (cf., e.g., [8]).
 4.
Similar definitions of rule morphisms can be found in the literature where the squares are pushouts instead of pullbacks, or simply commuting squares (e.g., [18]), or where the relations are between a single rule and a collection of rules (e.g., spatial and temporal refinements [4]). Requiring pullbacks is quite natural though: the intuition of morphisms is that they should preserve the “structure” of objects.
 5.
See [5] for a systematic classification of other definitions of GTS morphisms.
 6.
In effect, GTS transformers are a form of higherorder transformation [24].
Notes
Acknowledgements
This work has been partially supported by Spanish MINECO/FEDER project TIN201452034R and Univ. Málaga, Campus de Excelencia Internacional Andalucía Tech.
References
 1.Ehrig, H.: Introduction to the algebraic theory of graph grammars. In: Claus, V., Ehrig, H., Rozenberg, G. (eds.) 1st Graph Grammar Workshop, vol. 73, LNCS, pp. 1–69. Springer, Heidelberg (1979)Google Scholar
 2.Engels, G., Heckel, R., Taentzer, G., Ehrig, H.: A combined reference model and viewbased approach to system specification. Int. J. Software Eng. Knowl. Eng. 7(4), 457–477 (1997)CrossRefGoogle Scholar
 3.Ehrig, H., Ehrig, K., Prange, U., Taentzer, G.: Fundamentals of Algebraic Graph Transformation. Monographs in Theoretical Computer Science. An EATCS Series. Springer, Heidelberg (2006)Google Scholar
 4.GroßeRhode, M., ParisiPresicce, F., Simeoni, M.: Spatial and temporal refinement of typed graph transformation systems. In: Brim, L., Gruska, J., Zlatuška, J. (eds.) MFCS 1998. LNCS, vol. 1450, pp. 553–561. Springer, Heidelberg (1998). doi: 10.1007/BFb0055805 CrossRefGoogle Scholar
 5.Engels, G., Heckel, R., Cherchago, A.: Flexible interconnection of graph transformation modules. In: Kreowski, H.J., Montanari, U., Orejas, F., Rozenberg, G., Taentzer, G. (eds.) Formal Methods in Software and Systems Modeling. LNCS, vol. 3393, pp. 38–63. Springer, Heidelberg (2005). doi: 10.1007/9783540318477_3 CrossRefGoogle Scholar
 6.de Lara, J., Guerra, E.: From types to type requirements: Genericity for modeldriven engineering. SoSyM 12(3), 453–474 (2013)Google Scholar
 7.Durán, F., Zschaler, S., Troya, J.: On the reusable specification of nonfunctional properties in DSLs. In: Czarnecki, K., Hedin, G. (eds.) SLE 2012. LNCS, vol. 7745, pp. 332–351. Springer, Heidelberg (2013). doi: 10.1007/9783642360893_19 CrossRefGoogle Scholar
 8.Durán, F., MorenoDelgado, A., Orejas, F., Zschaler, S.: Amalgamation of domain specific languages with behaviour. J. Log. Algebraic Methods Program. (2015)Google Scholar
 9.Baldan, P., Corradini, A., Dotti, F.L., Foss, L., Gadducci, F., Ribeiro, L.: Towards a notion of transaction in graph rewriting. Electr. Notes Theor. Comput. Sci. 211, 39–50 (2008)CrossRefzbMATHGoogle Scholar
 10.Taentzer, G.: A visual modeling framework for distributed object computing. In: Jacobs, B., Rensink, A. (eds.) FMOODS 2002. IFIP, vol. 81, pp. 263–278. Springer, Boston, MA (2002). doi: 10.1007/9780387354965_18 CrossRefGoogle Scholar
 11.de Lara, J., Bardohl, R., Ehrig, H., Ehrig, K., Prange, U., Taentzer, G.: Attributed graph transformation with node type inheritance. Theoret. Comput. Sci. 376, 139–163 (2007)MathSciNetCrossRefzbMATHGoogle Scholar
 12.Diskin, Z., Maibaum, T., Czarnecki, K.: Intermodeling, queries, and kleisli categories. In: Lara, J., Zisman, A. (eds.) FASE 2012. LNCS, vol. 7212, pp. 163–177. Springer, Heidelberg (2012). doi: 10.1007/9783642288722_12 CrossRefGoogle Scholar
 13.de Lara, J., Guerra, E.: Towards the flexible reuse of model transformations: A formal approach based on graph transformation. J. Log. Algebraic Methods Program. 83(5–6), 427–458 (2014)CrossRefzbMATHGoogle Scholar
 14.GroßeRhode, M., Parisi Presicce, F., Simeoni, M.: Refinements of graph transformation systems via rule expressions. In: Ehrig, H., Engels, G., Kreowski, H.J., Rozenberg, G. (eds.) TAGT 1998. LNCS, vol. 1764, pp. 368–382. Springer, Heidelberg (2000). doi: 10.1007/9783540464648_26 CrossRefGoogle Scholar
 15.Harman, M.: The current state and future of search based software engineering. In: Briand, L.C., Wolf, A.L. (eds.) International Conference on Software Engineering, ISCE 2007, Workshop on the Future of Software Engineering, FOSE 2007, 23–25 May, Minneapolis, MN, USA, 342–357. IEEE Computer Society (2007)Google Scholar
 16.Durán, F., Orejas, F., Zschaler, S.: Behaviour protection in modular rulebased system specifications. In: MartíOliet, N., Palomino, M. (eds.) WADT 2012. LNCS, vol. 7841, pp. 24–49. Springer, Heidelberg (2013). doi: 10.1007/9783642376351_2 CrossRefGoogle Scholar
 17.Rozenberg, G. (ed.): Handbook of Graph Grammars and Computing by Graph Transformations, vol. 1: Foundations, World Scientific (1997)Google Scholar
 18.ParisiPresicce, F.: Transformations of graph grammars. In: Cuny, J., Ehrig, H., Engels, G., Rozenberg, G. (eds.) Graph Grammars 1994. LNCS, vol. 1073, pp. 428–442. Springer, Heidelberg (1996). doi: 10.1007/3540612289_103 CrossRefGoogle Scholar
 19.Orejas, F., Lambers, L.: Symbolic attributed graphs for attributed graph transformation. ECEASST 30 (2010)Google Scholar
 20.Orejas, F.: Symbolic graphs for attributed graph constraints. J. Symbolic Comput. 46(3), 294–315 (2011)MathSciNetCrossRefzbMATHGoogle Scholar
 21.Taentzer, G., Rensink, A.: Ensuring structural constraints in graphbased models with type inheritance. In: Cerioli, M. (ed.) FASE 2005. LNCS, vol. 3442, pp. 64–79. Springer, Heidelberg (2005). doi: 10.1007/9783540319849_6 CrossRefGoogle Scholar
 22.Cuadrado, J.S., Guerra, E., de Lara, J.: Flexible modeltomodel transformation templates: an application to ATL. J. Object Technol. 11(2), 4:1–4:28 (2012)CrossRefGoogle Scholar
 23.Guy, C., Combemale, B., Derrien, S., Steel, J.R.H., Jézéquel, J.M.: On model subtyping. In: Vallecillo, A., Tolvanen, J.P., Kindler, E., Störrle, H., Kolovos, D. (eds.) ECMFA 2012. LNCS, vol. 7349, pp. 400–415. Springer, Heidelberg (2012). doi: 10.1007/9783642314919_30 CrossRefGoogle Scholar
 24.Tisi, M., Jouault, F., Fraternali, P., Ceri, S., Bézivin, J.: On the use of higherorder model transformations. In: Paige, R.F., Hartman, A., Rensink, A. (eds.) ECMDAFA 2009. LNCS, vol. 5562, pp. 18–33. Springer, Heidelberg (2009). doi: 10.1007/9783642026744_3 CrossRefGoogle Scholar
 25.Hegedüs, Á., Horváth, Á., Ráth, I., Varró, D.: A modeldriven framework for guided design space exploration. In: Proceedings of the 26th IEEE/ACM International Conference Automated Software Engineering (ASE 2011), pp. 173–182, November 2011Google Scholar
 26.Zschaler, S., Mandow, L.: Towards modelbased optimisation: Using domain knowledge explicitly. In: Proceedings of Workshop on ModelDriven Engineering, Logic and Optimization (MELO 2016) (2016)Google Scholar
 27.Fleck, M., Troya, J., Wimmer, M.: Marrying searchbased optimization and model transformation technology. In: Proceedings of the 1st North American Search Based Software Engineering Symposium (NasBASE 2015) (2015) (Preprint). http://martinfleck.github.io/momot/downloads/NasBASE_MOMoT.pdf
 28.Clavel, M., Durán, F., Eker, S., Lincoln, P., MartíOliet, N., Meseguer, J., Talcott, C.L.: All About Maude, vol. 4350. LNCS. Springer, Heidelberg (2007)Google Scholar
 29.Brim, L., Gruska, J., Zlatuška, J. (eds.): MFCS 1998. LNCS, vol. 1450. Springer, Heidelberg (1998)Google Scholar