A Graphical Specification of Model Composition With Triple Graph Grammars Adil Anwar 1, Amine Benelallam 2, Akram Idani 3, Bernard Coulette 4, and Mahmoud Nassar 2 1 Siweb, Computer Science Department, EMI, Mohamed Vth Agdal University, Rabat, Morocco anwar@emi.ac.ma 2 IMS-SIME ENSIAS, Rabat, Morocco nassar@ensias.ma,amine.benelallam@um5s.net.ma 3 University of Joseph Fourier, Grenoble INP, CNRS 38402 Saint Martin dheres Cedex, France Akram.Idani@imag.fr 4 IRIT-UTM, University of Toulouse II, Toulouse, France coulette@univ-tlse2.fr Abstract. The concept of model is widely used in the MDE approach in order to represent several software artifacts, which are handled by different development teams throughout the software life cycle. Management of these models requires the definition of a set of model management operators such as the composition operation. This is generally an operation, which is dedicated to merge a number of models in order to create one (or more) incorporated model and which depends on the application context. The current work focuses on the description of a formal approach for model composition where the composition is specified by a set of graph transformation rules over UML-compliant models. The semantics of our composition operator is defined using triple graph grammars (TGGs) formalism. Furthermore, we present a composition scheme interpreted by a three-steps composition process: matching, checking and merging. Keywords. : Model composition, model-driven development, graph transformations, triple graph grammars, AGG. 1 Introduction Model composition is a crucial activity in Model Driven Engineering (MDE). It is particularly useful when adopting a multi-modeling approach to model large and complex software systems. The main purpose is to separate concerns in order to represent the software system as a set of less complex sub-models. Each model represents a view of the system according to different perspectives [6], different concerns, different components, and so on. The aim is to reduce the complexity of the analysis/design activities in the earlier phase of the software development process. However, this may increase the complexity of the integration of the various sub-models in a later phase.
The Model-Driven Engineering (MDE) approach is a powerful way to express and automate or semi-automate some integration operations. Thus, numerous works have adopted MDE techniques in order to define model composition as model transformations [11] [3]. Furthermore, we proposed, in a recent work [2] a formal approach for model composition in which we consider composition as an algebraic operator on the set of UML-compliant models. According to several studies, models and metamodels can thus be represented by a graph-based structure [13]. Graph transformation theory also provides a formal support for defining some activities related to model management such as model transformation [1] [15], model refactoring [13], model synchronization [9] and model integration [12]. For these reasons, we believe that graph transformation to be a powerful technology for specifying and applying model composition in an MDE process. Furthermore, using graph transformations as the underlying theory to formalizemodel composition as a special kind of model transformation, allows taking advantage of the diversity of existing graph-based tools such as AGG [17], Fujaba [14] and Great [1]. In this paper, we propose a novel approach that addresses the model composition problem by means of graph transformations. The core idea is to use the Triple graph grammars formalism to specify the composition operator with a set of visual and formal graph transformation rules. Using TGGs for model composition offers many conveniences, especially good understanding, simplicity for declaratively expressing composition rules, and also suitable technique with formal analysis tools. In particular, critical pair analysis that can be used to automatically detect dependencies and conflicts between graph production rules. The remainder of the paper is structured as follows. In section 2 we first introduce an example based on a case study that will illustrate our composition approach. In section 3, we explain our approach for specifying model composition as an application of triple graph grammars and we discuss some experiment details of our approach. Related works and issues raised by our work are discussed in section 4. Section 6 summarizes our contributions and sketches out some future works. 2 Running example In this section, we first give a brief overview of the modeling approach, then describe our composition process through a case study that serves as a running example for explaining the composition approach. 2.1 Motivating Example In this example, we need to merge two UML models that have been developed independently of each other. We illustrate the merging scenario through a Course Management System (CMS). The CMS system is designed using an
actor-centered process (student, teacher and system administrator). These actors have different concerns corresponding to view-points from which the system can be modeled. In this paper, we focus our study on structural models (class diagrams). Figure 1(a) shows an excerpt of the class diagram of the Students viewpoint. For teacher and system administrator viewpoints, a similar process is performed and produces class diagrams that model the specific requirements of associated actors (Figure 1 (b)). (a) Excerpt of the class diagram of Student s actor (b) Excerpt of the class diagram of Teacher s actor Fig. 1: Two viewpoint models of the CMS 2.2 Overview of the composition process Existing research [11] has demonstrated that model composition process can be decomposed into three activities, as depicted by Figure 2 below. Model composition includes different tasks. First, it defines correspondence relationships among design models, and then analyzes the correspondences in order to merge these models according to those correspondences. This separation facilitates the maintainability of the composition process since the matching operation is more stable than the merging operation which is subject to strategy modifications. We propose a composition scheme, which is made of tree steps: matching, correspondences checking and merging (Figure 2). Matching Step In this step, we need, on the one hand, to identify corresponding elements in the input models. On the other hand, we may need to express certain kinds of relationships between those elements. A notable example of such correspondence relationship is equality stating that two or more elements are equivalent, which means that they represent consistent views of the same concept. Another example of possible relationships is similarity stating that two or more elements are similar in some respects but not equivalent. For example,
Fig. 2: Composition process of the design models expressing similarity relationships is very useful in order to distinguish operations that appear with the same signature (name, type, parameters) but do not have the same behavior. Correspondences checking step The purpose of this step is to check and validate the correspondence relationships identified in the previous step. The designer may identify potential conflicts between input models. For example, one can identify similarity relationships relating two classes that represent the same concept appearing in two or more models with different names. Elements that have been identified as matching in the previous phase are examined for validation. Other types of relationships such as generalization, aggregation, dependency, etc. may be specified manually. Merging Step This is a relationship-driven merging step. This step aims at producing the composed model. In fact, different merging strategies can be applied according to each correspondence relationship. For example, we have identified two merging strategies: merge and translate. The Merge strategy is applied to elements that are related to each other through equality relationships. This is a nominal merging scenario which is applied to overlapping elements among multiple models. Elements that have no correspondent in the opposite model are simply translated into the composed model while following the translation rules. By applying this composition process to the CMS example, we obtained the class diagram resulting from the composition of the two class diagrams shown above (Figure 1 (a) and Figure 1(b)). We added some stereotypes to the classes of the merged model so one can trace back which classes originated from only one input model and which ones existed in both of them (Figure 3). For example, classes named Exercise and Course appear in the merged model with the merged stereotype. Otherwise, the merge process marks classes that appear only in one source model, with the stereotype actor (e.g Registration class). It should be
noted that we defined a tag value named actorname which can trace back the actors from which the class originated. Fig. 3: Excerpt of the global class diagram of CMS system 3 Composition Approach In this section we present our approach, which implements triple graph grammars [15], and how we can use it for model composition. Triple graph grammars offer a formalism to declaratively and visually describe bidirectional model transformations. This technology is suitable for addressing the problem of model transformation using the QVT-MOF standard 5. Furthermore, it can also be used to achieve many tasks and applications related to model-driven development process such as model refactoring [13], model synchronization [10], model integration [12],etc. In practice several tools and environment [17] [14] illustrate the application of triple graph grammars to implement model transformation with respect to basic concepts of the MDE approach. In the TGGs formalism, graph rewriting rules relate object pattern from both source and target pattern models. A TGG rule can be interpreted in different ways depending on the transformation direction. For example TGGs rules can be used to transform one graph into another graph (forward or backward transformations) or to check if two graphs structurally correspond to each other by generating a third graph, the correspondence graph [10]. 3.1 Representation of Models According to several studies [8], MOF-compliant models are intrinsically graphs. Following this, we adopt attributed and directed labelled graphs as the basis for our model representations. 5 www.omg.org/spec/qvt/1.1
In the following, we assume that viewpoints models (class diagrams in this paper) are formally defined as attributed graphs. Indeed, each vertex or edge can contain zero or more attributes. Such an attribute is typically a name-value pair that allows attaching a specific value to each attribute name [13]. Fig. 4: Example of a graph representing the UML class diagram modeled in Figure 1(a) As an example of an attributed graph we consider Figure 4 above. Its effectively attributed in the sense that all of its vertices contain attributes. Such an attribute is typically a name-value pair. For example, the AssocaitionEnd node that represents the Course AssociationEnd has an output edge that is labeled type and target the class node Course. This is mean that the Association courseexercise has as extremity of kind aggregation the Class Course according to the teacher class diagram (Figure 1(a)). 3.2 Metamodeling We use metamodels that conform to MOF 1.4 6. Furthermore, metamodels are also used in order to specify our composition rules in the TGGs formalism. In our composition example, source and target metamodels are defined by the UML metamodel. We also use a third metamodel which we call composition metamodel. This metamodel allows defining all the link types for the graphical specification of composition rules. In the world of model driven engineering, we say that a model is conform to its metamodel, the same idea may be applied with the concept of graphs world, 6 http://www.omg.org/spec/mof/1.4/
and we say that a graph needs to conform to a so-called type graph or a graph schema [12]. A type graph defines the type of nodes and edges types and also constraints between nodes and edges. According to our composition process, we need to maintain and create matching links between input model elements from the matching step. In our approach, we require that matching links be used for merging. So, we create all of the matching link types we need by specializing the MergeRelation link type declaration. This link type, when specialized, defines a mapping link type for each element type from source metamodels and will be used in the merging step to produce elements in the merged model. For example an instance of the link type ClassMergeRelation maps classes that are defined as equivalent in source models. This link type will be used later by a merging rule to produce a merged class from the related source classes. Fig. 5: Simplified UML Class diagram and composition metamodels 3.3 Expressing Composition Rules with TGGs In the TGGs formalism, graph rewriting rules graphically specify how objects from a pair of graphs are related using a third graph, so-called correspondence
graph. Actually, each TGGs rule is composed of a pair of graph rewriting rules and a third graph rewriting rule which is used to check and create correspondence links between nodes of both considered graphs [12]. A graph rewriting rule consists of two parts, a left-hand side and a right-hand side. A rule is applied by substituting the objects of the left-hand side with the objects of the right-hand side, only if the pattern of the left-hand side can be matched to a given graph. As said earlier, TGGs rules are declarative specifications of bidirectional graph transformations. In this section, we explain how, from these declaratives specifications, we derive some transformation rules for merging purposes. We structured those transformation rules into three categories: matching, merging and translation rules. To explain our transformation rules, we use a graphical notation close to Fujaba-notation [14] for easy understanding. In this notation, white nodes represent nodes that appear on both the left and right sides of the graph rewriting rule. The colored nodes, also marked with the stereotype <<new>> are those that are additionally produced in the rule (Figure 6). Matching Rules To perform the matching transformation, we apply TGGs rules in a correspondence transformation scenario. In this scenario, there is actually no model transformed, input models are considered as source and target models of the transformation. TGGs rules are applied to calculate a valid correspondence between two existing graphs [10]. For this purpose, both source and target graph grammar sides are matched with the existing graph elements. Then, the correspondence graph pattern is created. If such a correspondence transformation is performed successfully, the created correspondence nodes represent the matching links of the two given models. Fig. 6: TGG rule createclassmatchinglink Figure 6 shows a rule, which creates a ClassMergeRelation correspondence link. To create this link between two classes, first, they must have the same name as specified by the constraint. Then, they have to be defined in two separate models linked to each other by a ModelMergeRelation. The correspondence link ModelMergeRelation acts as an application context of the rule ClassMergeRelation. This means that the rule that create the link ModelMergeRelation has to be triggered first. Note that, we omitted a negative
application condition, which prohibits multiple applications of this rule and the creation of more than one correspondence link. We recall that during the checking correspondence step (Figure 2, the designer can manually introduce other matching links in order to relate elements that represent the same concept but are modeled differently. This is one of the advantages of this approach, which clearly separates the matching and merging activities. Merging Rules The basic idea of the merging The basic idea of the merging transformation is to consider the regarded models plus the matching links, identified in the previous step, as a single graph (input graphs + matching links). Merging rules compute different matching links in order to produce equivalent elements in the merged model. Fig. 7: A TGGs rule merging two input classes Figure 7 shows a TGGs rule which specifies the generation of a new class and linking it to an existing merged model. The target production of the rule also specifies the generation of the merged stereotype according to our merge strategy. Again, a negative application condition has been suppressed to increase the readability of the transformation rule. Finally, the merged class diagram and the inputs class diagram must already be linked by a correspondence link of type ModelMergeRelation. Translation Rules Translation rules deal with elements that are not identified as equivalent in the matching step. The default strategy of a translation rule consists only in creating, in the target model, a deep copy of the source element on which it is applied. Figure 7 presents an example of a translation rule that translates an isolated class into the merged model. This rule creates, in the merged model, a target class and a stereotype (Figure 8) with the provided values for their attribute names. For this purpose, the merged model must have been previously created by the merging rules to which the newly created object
will be attached to. Finally, we need to specify a negative application condition to ensure that the source class is not being related by a matching link. Fig. 8: A TGGs translation rule transforming a class to the merged model 3.4 Implementation In this section we introduce some experiments we have performed with AGG tool [17]. AGG is a rule based visual language supporting an algebraic approach for graph transformation. Its provides some additional features of TGGs that are needed to express complex transformations. Some of these features include specific attribute constraints also called context constraints, Positive, Negative, and General Applications Conditions (PACs, NACs, and GACs). The GACs have the possibility to apply combinations of former operators like AND, OR, FORALL over patterns. AGG is also useful in order to validate graph grammars using consistency checking and critical pair analysis techniques such as parallel conflicts and sequential dependencies [5]. Finally, it is possible in AGG to specify a control flow of graph transformation by using rule layers and priority order [7]. Thus, layers set the order in which graph production rules are applied. Specifying composition type graph In AGG, metamodels are specified as type graphs. It is possible to define typed attributed graphs with node type inheritance, but transformation rules and application conditions do not yet support node inheritance. That is why we adopted the classical representation with no node type inheritance.each package(figure 5) is represented by a sub-graph. the three sub-graphs represent the type graph of our composition approach. Specifying rule layers So as to have the same logical order as in the composition process, we used rule layers to specify the transformations flow and decrease the complexity of the transformation application conditions. Thus, the matching rules appear first, the transformation rules come after the application of merging
rules, and, obviously, the deletion rules come after the transformation process. Figure 9 depicts composition rules sorted by rule layers. Fig. 9: Rules layers Figure 10 below illustrate a concrete example of a TGG rule in AGG tool. An AGG rule consists of a left hand side (LHS) and a right hand side (RHS). The LHS panel displays the sub-graph to look for, and the RHS displays the modifications over the LHS. Fig. 10: TGG rule ClassMergeRelation in AGG notation Specifying rules with AGG Figure 10 sketches the rule that merges classes. For a pair of classes having the same name and belonging each to an already merged class diagram (LHS), we generate a merged class with the same name and a merged stereotype which connects the merged class to the merged class diagram. The default NACs guarantees that rules are applied to a match only once. AGG offers an attribute context editor to declare variables and attribute condition definitions. For example, we used this feature to ensure that the class names are equal in the class merging rule.
Fig. 11: Merged graph To test composition rules, we consider the input models in figures 1(a) and figure 1 (b). To increase the clarity and the readability of the paper, we excluded some attributes and operations. Figures 11 depicts the merged model resulting from the application of all the TGGs rules. Consistency checking with AGG A consistency check can be performed on the output model using consistency conditions (CC). A consistency condition graphically describes graph properties like the existence of a particular element or the independence of a particular rule. Furthermore, a consistency condition is composed of a premise P and a conclusion C. For example, figure 12 describes a consistency condition that specifies how to check that every class has necessarily a stereotype with an attribute named actor or merged. The premise of the CC is the node Class, and the conclusion is a class connected to Stereotype with an attribute name actor or merged. When checking this CC on our output model a window appears with the message the graph fulfills this atomic. AGG also computes the graph of sequential dependencies between rules, in order to detect early defaults and verify the behavior of the transformation. We computed this graph for the all the transformation rules in our composition process. This implementation was an important step to validate our composition process, and discover the difficulties related to the use of a graph transformation tool. Most of the difficulties are similar to those flagged in [13]. When handling
Fig. 12: Check Class stereotypes constraint complex metamodels with inheritance and aggregation links, defining the type graph becames more difficult. Besides, AGG supports neither OCL 7 nor any OCL-derived language. This could have been very helpful whenever one of the OCL collection operators is needed. 4 Related Works Model composition has become an important activity in the model-driven engineering field. A number of related approaches are based on model transformations. In this section, we review some proposed approaches to model composition and discuss their strong and weak points. We focus on works that are close to ours, by means of using graph transformation formalisms and model driven engineering techniques. The MDI (Multi Document Integration) approach presented in [12] generalizes the formalism of TGGs with the concept of multi-graph grammars and proposes an approach for heterogeneous and distributed data integration. The integration process is based, on the one hand, on a set of declarative rules called data integration rules. Declaratives rules are used to specify correspondence links between the involved models. On the other hand, from those rules, they derive a set of operational rules that ensure consistency between models and are responsible for attribute changes propagation from one element to the linked one. Attribute constraints defined by TGGs being relatively simple, we propose in our approach the use of Layered graph grammars which make possible to reduce the complexity of attribute constraints. The approach presented in [16] elaborated a framework foelaborated a framework for model management using RGGs (Reserved Graph Grammars). RGGs are developed based on layered graph grammars using the layered formalism to allow the parsing algorithm to determine, in a finite number of steps, whether a graph is valid. Model management operators are specified at two levels, specific and generalized. A specific operator is a low level description presenting a concrete image of the expected output and interface. The generalized operator specifies, using RGGs rules, the operators behavior. Namely, the Merge operator 7 http://www.omg.org/spec/ocl/2.2/
takes three inputs, a model A, a model B, and a mapping between A and B, and returns the union model C of A and B along with mappings between C and A, and between C and B. This approach does not compute the mapping model between A and B, which means that the correspondence step is not automated. Finally, the MOMENT framework [4] is an EMF-based framework for model management that provides a set of generic modules and operators such as the merge operator. It is based on three concepts: the equivalence relation, conflict resolution strategy and the construct refreshment which are respectively equivalent to the matching, merging and transcription steps. The Merge operator uses the equivalence relation defined for a metamodel to detect duplicated elements between the two input models. This approach assumes that input models are consistent and do not handle complex relationships like the Aggregation relationship. This makes the matching step easy to automate. The approach tackles change propagation instead. 5 Conclusions and Future Work This work aimed to formalize the model composition activity so as to produce a composed model that represents an integrated view of all the individual views. For this purpose, we considered the composition operation as a global operation decomposed into two atomic model management operations that are model matching and model merging. The formalization of our model composition operation is described graphically using graph transformations. We used the TGGs formalism to graphically specify a set of composition rules over a set of UML-compliant models. Attributed graphs are used in order to provide a formal representation of both source and target models and also the correspondence model. Truly, the matching operation aims to add a set of links to source model elements. The merging operation is viewed as a homogeneous model refactoring transformation. The merging strategy of related elements depends on their merging relation type. Using the correspondence graph, it is easy to automate the merging step and allow incremental refinement of the correspondence graph. Furthermore, it also allows to enhance the traceability of the composition process. This reported work can be extended in many directions. First, our approach was defined and validated in the context of UML models represented by class diagrams, but it is quite generic since most of our formalization deals with graphs properties. So it could be easily applied to the composition of any graph-based models. Automating the identification of potential concordances or inconsistencies between partial models may be an important step for applying the presented approach to large-scale projects. Thus, we could use matching heuristics to perform similarities computation between graph-based models. The similarity values will use relational and attribute related knowledge to identify semantic correspondences between elements.
References 1. A. Agrawal, G. Karsai, S. Neema, F. Shi, and A. Vizhanyo. The design of a language for model transformations. Software and Systems Modeling, 5(3):261 288, 2006. 2. A. Anwar, T. Dkaki, S. Ebersold, B. Coulette, and M. Nassar. A formal approach to model composition applied to vuml. In Engineering of Complex Computer Systems (ICECCS), 2011 16th IEEE International Conference on, pages 188 197. IEEE, 2011. 3. A. Anwar, S. Ebersold, B. Coulette, M. Nassar, and A. Kriouile. A rule-driven approach for composing viewpoint-oriented models. Journal of Object Technology, 9(2):89 114, 2010. 4. A. Boronat, J.Á. Carsí, I. Ramos, and P. Letelier. Formal model merging applied to class diagram integration. Electronic Notes in Theoretical Computer Science, 166:5 26, 2007. 5. P. Bottoni, G. Taentzer, and A. Schurr. Efficient parsing of visual languages based on critical pair analysis and contextual layered graph transformation. In Visual Languages, 2000. Proceedings. 2000 IEEE International Symposium on, pages 59 60. IEEE, 2000. 6. M. Chechik. A relationship-based approach to model management. In Model- Based Methodologies for Pervasive and Embedded Software, 2009. MOMPES 09. ICSE Workshop on, pages 1 1. IEEE, 2009. 7. H. Ehrig, K. Ehrig, J. De Lara, G. Taentzer, D. Varró, and S. Varró-Gyapay. Termination criteria for model transformation. Fundamental Approaches to Software Engineering, pages 49 63, 2005. 8. H. Ehrig, U. Prange, and G. Taentzer. Fundamental theory for typed attributed graph transformation. Graph Transformations, pages 161 177, 2004. 9. H. Giese and R. Wagner. Incremental model synchronization with triple graph grammars. Model Driven Engineering Languages and Systems, pages 543 557, 2006. 10. J. Greenyer and E. Kindler. Reconciling tggs with qvt. Model Driven Engineering Languages and Systems, pages 16 30, 2007. 11. D. Kolovos, R. Paige, and F. Polack. Merging models with the epsilon merging language (eml). Model Driven Engineering Languages and Systems, pages 215 229, 2006. 12. A. Königs and A. Schürr. Mdi: A rule-based multi-document and tool integration approach. Software and Systems Modeling, 5(4):349 368, 2006. 13. T. Mens, N. Van Eetvelde, S. Demeyer, and D. Janssens. Formalizing refactorings with graph transformations. Journal of Software Maintenance and Evolution: Research and Practice, 17(4):247 276, 2005. 14. J. Niere and A. Zündorf. Using fujaba for the development of production control systems. Applications of Graph Transformations with Industrial Relevance, pages 301 304, 2000. 15. A. Schürr. Specification of graph translators with triple graph grammars. In Proceedings of the 20th International Workshop on Graph-Theoretic Concepts in Computer Science, pages 151 163. Springer-Verlag, 1994. 16. G. Song, K. Zhang, and J. Kong. Model management through graph transformation. In Visual Languages and Human Centric Computing, 2004 IEEE Symposium on, pages 75 82. IEEE, 2004. 17. G. Taentzer. Agg: A tool environment for algebraic graph transformation. Applications of Graph Transformations with Industrial Relevance, pages 333 341, 2000.