Supporting the Automatic Generation of Advanced Modelling Environments with Graph Transformation Techniques Esther Guerra
Paloma Díaz
Juan de Lara
Dept. Informática
Dept. Informática
Escuela Politécnica Superior
Universidad Carlos III Universidad Carlos III Madrid, Spain
Madrid, Spain
Madrid, Spain
[email protected]
[email protected]
[email protected]
Abstract In this paper we show our approach to the automatic generation of modelling environments for Visual Languages (VLs) supporting multiple views. The approach is based on the metamodelling tool AToM3 . Starting from a metamodel description of the VL and its views, a customized modelling environment is generated. Consistency between views is supported by the automatic generation of triple graph grammar rules that build a unique model “gluing” all the view models. Moreover, the generated environments allow taking basic static metrics of the models. Extreme values of the metrics may trigger heuristics for the refactoring of the models. These heuristics are formalized in the form of graph grammar rules. We show the application of these concepts in the area of hypermedia design by generating an environment for the Labyrinth VL.
1
Universidad Autónoma
Introduction
The use of diagrams is pervasive in today’s software engineering practice. They are intensively used in the planning, analysis and design phases of software development, as a means for problem specification, understanding and reasoning. Moreover, domain specific visual languages (DSVLs), specially devised for particular knowledge areas are becoming ever more popular. They are useful, as they provide users with high-level constructs, adapted to the task to be performed, thus boosting pro-
ductivity and improving quality. One of such DSVLs is Labyrinth [5], a set of notations for the analysis and design of hypermedia applications. As systems become increasingly complex, a separate description of their different characteristics helps in managing such complexity. In this way, many DSVLs are indeed composed of sets of diagrams, each one of them used for the description of different aspects of the system. For example, in the UML2.0 specification, one finds diagrams for the description of the structure (class and object diagrams) and behaviour (statecharts, communication diagrams, etc.) of the system. Thus, there is a need for methods helping in the definition of DSVLs supporting multiple views. Furthermore, the method should support the consistency of their different views and provide analysis mechanisms for the described system. Graph transformation [6] is a formal means to manipulate graphs, based on rules. Rules are made of left and right hand sides (LHS and RHS). Roughly, in order to apply a rule to a graph, a match morphism has to be found between the LHS and the graph. Then, the matched part of the graph can be substituted by the RHS. As diagrams can be represented as attributed, typed graphs, graph transformation is a suitable framework for model manipulation. Its appealing is that it is a graphical, natural and formal way to express computations. Its theory can be used to analyze the properties of the transformations themselves. Thus, we use graph transformation for
model transformation (into a different notation), model simulation and optimization. In this paper, we propose using metamodelling for the description of the DSVLs syntax and their different views. From this high-level description, a customized modelling environment is automatically generated supporting multiple views. View consistency is ensured by building a unique model, “gluing” all the view models. We call such a model repository model, and should be a correct instance of the whole DSVL meta-model. Some automatically generated graph grammar rules translate each view model into the repository model, performing the appropriate checkings. These ideas have been newly integrated in the meta-modelling tool AToM3 [3]. Moreover, in the generated environment, we can specify model optimizations or refactorings [7] in order to improve certain model characteristics. For example, we may move common features of different classes to their superclass. These refactorings are formalized in the form of graph transformation rules. In addition, the generated tool supports basic static metrics that can trigger refactorings to improve the design in parts of the model where these metrics reach extreme (i.e. bad) values. As the optimizations are specified as graph transformation rules, it is possible to analyze the properties of the model refactoring. The rest of the paper is organized as follows. Section 2 informally presents some necessary background on meta-modelling and graph transformation. Section 3 explains our approach, based on AToM3 , for the specification and automatic generation of multiple views modelling environments. Section 4 presents a non-trivial example of the generation of a modelling environment for Labyrinth (which has 16 views). Section 5 compares with related research and finally section 6 ends with the conclusions and prospects for future work.
2
Meta-Modelling Transformation
and
Graph
Meta-modelling allows the description of a set of valid models by building another model that
describes them: the meta-model. This is usually specified using notations such as class or entity-relationship diagrams. In order to further restrict the admissible models, additional constraints can be set on the meta-models. These are sometimes specified using textual languages. Meta-modelling is a quite common approach for the description of diagrammatic notations. For example, UML was defined using a four-layer meta-architecture. The UML meta-model is at the third level. One level below user-defined UML models are placed. One level above, we find the description of the language in which the UML meta-model was described: a core subset of class diagrams. Note how, the notations at the fourth meta-layer can be described with themselves. In order to specify a VL, one has to describe its abstract syntax (the language concepts) as well as its concrete syntax (the graphical rendering of the VL concepts). The first kind of syntax is captured in the meta-model. For the second one, several approaches exist. In the AToM3 tool, this is given by special graphical attributes that are assigned to each class and relation in the meta-model. From this high-level specification, AToM3 can generate a customized modelling environment for the VL. The functionality of such tool can be enriched by defining graph transformations to manipulate the models. The basics of this technique are explained next. Graph transformation [6] is a formal means to manipulate graphs based on rules. In analogy to Chomsky grammars on strings, graph rules are made of left and right hand sides (LHS and RHS), both containing graphs. Intuitively, when applying a rule to a graph (called host graph), a match morphism should be found between the LHS of the rule and the graph. If such morphism is found, the rule can be applied. Then, the matched part in the graph can be substituted by the RHS of the rule. This process is called a derivation step. An example is shown in Figure 1, where a rule is applied to a graph. This rule simply removes a “permission” relation from a subject node if such relation is also defined on another one, which composes the former.
Graph Grammar Rule
LHS:
1
5
permission
Subject
3
Function Component
composition 4 2
Subject
permission
6
permission
Function
5
permission 3
2
Function Component
Subject
permission
Function
Subject
Function
permission
Composite Subject
Team composition
Composite Function
1
Subject
composition permission
Function Component
RHS: composition 4
Team
Role
Excerpt of Labyrinth Meta−Model
Role
Team composition
Role
(ii) match of LHS in graph
composition
Role
composition
Role
(iii) graph after the rule application
Figure 1: A Rule Application.
We combine meta-modelling and graph transformation allowing abstract nodes to appear in rules [2]. In this way, nodes can be matched to instances of any subclass, greatly improving the expressive power of rules. For example, in Figure 1, Subject nodes can be matched to either Team or Role nodes. Similarly, Function Component can be matched to Function or Composite Function nodes. The applicability of a rule can be further restricted by specifying application conditions. A condition has a premise graph X, a set of consequent graphs Yi , and morphisms yi from yi Yi }. If a match X to each Yi : c = {X, X −→ is found for X in the host graph, then a match has to be found for every consequent node Yi for the rule to be applied. If a condition does not have consequent graphs, finding a match for the premise forbids the rule application. This is a special case of condition called negative application condition (NAC). On the contrary, if the condition has an empty premise, it is a positive application condition. The Double Pushout (DPO) approach [6], followed in this work, uses category theory in order to formalize rules and their application. In this approach, rules are represented as three graph components and two injective span morl r phisms: L ←− K −→ R. K is called the interface graph and contains the preserved elements by the rule. L−K and R −K are the elements deleted and added by the rule application respectively. A rule application is modelled by two pushouts in the Graph category. Note
how the categorical framework is independent of the concrete category used. For multiple views environments, we are interested in rewriting graph triples by means of triple graph grammars [12] (TGGs). Graph triples are made of two view graphs (V IEWi ) and an intermediate graph (LIN K) relating objects of both views. That is, nodes in LIN K have pairs of morphisms: one to V IEW1 objects and another one to V IEW2 objects. Thus a graph triple is depicted as v1 v2 LIN K −→ V IEW2 . In this V IEW1 ←− work, V IEW1 is the repository model, and TGGs are used to specify how the different view models are glued in it. In [9] we defined TGGs using the DPO approach and used them in combination with meta-modelling.
3
Generation of Multiple Views Modelling Environments
In the meta-modelling approach, a VL is specified by means of a meta-model, which is used to automatically generate a modelling environment. If the VL has multiple views, in the simpler case, their meta-models are subsets of the VL meta-model. Some problems arise if the meta-models of two or more views share common elements. For example, different values might be assigned to the same attribute of an element present in several view instances, resulting in non-coherent designs. Therefore, sometimes it is useful to have a perspective of the whole system and not only of different isolated view instances. In this work we overcome these problems by constructing a unique model – the repository – by gluing the different view models through the shared elements. We have implemented these ideas in the AToM3 meta-modelling tool, using in most cases its code generation features. In this way, the core of a new tool to specify the views of a certain VL was defined by means of the meta-model in Figure 2. It is made of a single class named View and a relationship view_consistency. The class attributes are a unique name, a list of generative attributes [3] (the ones that will be shown in the generated environment), a
view_consistency
0..*
+ name: String {keyword} + grammar: TripleGraphGrammar
View + name: String {keyword} + attributes: List of Attribute + appearance: Appearance + minCard: Cardinality + maxCard: Cardinality + metamodel: Model
0..*
Figure 2: “Views” meta-model.
graphical appearance, the minimum and maximum number of allowed instances of a certain view in a model, and a meta-model handler for specifying the corresponding view metamodel. Relationship view_consistency represents consistency validations between two (usually different) views. Their only attributes are its name and a triple graph grammar handler. With this meta-model, a tool has been automatically generated and integrated with the class diagrams meta-metamodel (that we use to define the VLs). In this way, once a VL meta-model is defined, the generated “Views” tool can be opened to define the VL views. A snapshot of this tool is shown in Figure 3. The figure shows some of the views for the Labyrinth VL. One view, called repository, containing the complete meta-model is always added by default. This view is used to keep a unique model containing the “glued” view models edited by the final users. In addition, VL designers can add as many views as necessary. By default, new views contain the complete VL meta-model. This can be edited afterwards by clicking the view icon on the canvas. A restrictive approach has been implemented, so VL designers are only allowed to remove classes and relationships from the default meta-model, or edit the remaining ones to remove their attributes and constraints. In addition, the graphical appearance, the cardinality and a list of attributes can be specified for the view. 3.1
Consistency
In the “View” tool, consistency among views can be ensured by means of relationship view_consistency, where TGGs can be defined
Figure 3: “Views” tool.
with this purpose. We use triple rules because they easily allow relating meta-models of two views through a correspondence graph. Changes in some view model will fire the TGGs defined in the incoming and outgoing view_consistency relations for the edited view. The tool automatically generates some consistency relations, with the associated TGGs, for the common coherence mechanisms between the views and the repository. In particular, one relation between each view and the repository is generated. The included TGGs contain rules to ensure consistency among views in case of users create, remove or edit items of a view model. In this way, for each concrete class and relationship in the view meta-model, such set of rules is generated. We do not generate the rules for abstract elements, as they cannot be instantiated. Briefly, the automatically generated rules regarding object creation relate the newly created object with a single copy of itself stored in the repository. This repository copy is referenced by the same object appearing in different view models. Rules for deletion remove from the repository elements not referenced in any view. Finally, edition rules copy the attribute values in views to the related attributes in the repository, if they are different. Then, the new attribute value should be propagated to the related items in the remaining views. A
TGG in opposite direction performs this task. Section 4.1 shows a detailed example of these rules for the Labyrinth VL. Apart from these generated relations, VL designers can create their own consistency relations for particular purposes (e.g. check the existence of some item in a view before using it in another view), or other nontrivial procedures (e.g. if concrete and abstract syntax are quite different, as in UML [9], extra rules should be provided). 3.2
Metrics and Refactoring
Since a unique model containing the sum of the different models is built and stored in the repository, we can use regular graph grammars to manipulate it with several purposes. On the one hand, we can transform it into some semantic domain for simulation and functional verification [8]. The repository model is not changed, but feedback with the results is shown to the users. On the other hand, we can change the model structure to improve the quality of the software design [11]. Some of these design improvements are only detectable on the whole model, but not in the isolated views. In this case, changes in the repository should be propagated to the different view models for maintaining the required consistency. Of course, structural changes can also be performed in some particular view, letting the consistency rules restore the consistency of the whole system. In section 4.2 will provide some example of refactoring rules defined for a real case. The tool also supports taking some basic static metrics of general purpose for the repository model (e.g. number of objects of every class, incoming or outgoing relationships from each object, etc.). These metrics can automatically fire the execution of a regular graph grammar for design refactoring when some extreme value is reached.
4
An Application to Hypermedia
Labyrinth [5] is a set of notations for the design of platform-independent hypermedia ap-
plications. It provides the elements for the description of both static structure and dynamic behaviour of this kind of applications. A very little excerpt of its meta-model is shown to the left of Figure 1. With this notation, hypermedia systems are described like a set of nodes where several contents (e.g. texts or pictures) are placed. Links among nodes establish the way users are allowed to navigate in the system. In addition, users can assume some roles and take part in different teams, each one assuming a set of permissions. The Ariadne Development Method [4] uses Labyrinth in the process of building hypermedia applications. It proposes a set of artefacts that are mappings to different views of the Labyrinth meta-model. For example, an artefact called User Diagram is used to specify roles and teams hierarchies. The meta-model for this artefact contains only the necessary classes and relations (e.g. class Role is included, but class Function is not). In short, Ariadne defines 16 design artefacts, or in the same way, 16 views over the Labyrinth metamodel. One environment supporting the Ariadne’s products has been generated with AToM3 . For this purpose, we started defining the whole Labyrinth meta-model in the tool. Then, the 16 views were taken out from the meta-model, one for each product. By default, AToM3 allows VL designers to add any number of models of one view in their projects. Nevertheless, we had to restrict some views to only one instance, and others to at least one in order to encompass the Ariadne method features. In addition, every view was completed with a name and a description. No consistency relations were provided, only the ones generated by the tool were necessary. A snapshot of the generated tool is shown in Figure 4. Buttons on the left of the background window allow adding a new model of a certain view to the project. The new added model is shown in the canvas as an icon. If the user clicks on the icon, a control dialog allows editing the view attributes (“name”, “description” and the model). The foreground window in the same figure shows the edition of the
model corresponding to one User Diagram.
Figure 5 shows the generated rules for handling creation of Role instances in view models. The upper rule creates a role in the repository if it detects a newly created role in a view model. The NAC guarantees that the role does not already exist in the repository, so it is new. The rule below relates a newly created role with an existing one in the repository with the same identifier. The “refcount” attribute for the role in the repository counts how many references a role has. When a role is created in the repository, its value is set to 1. The counter is incremented every time a view model includes the same role in it. NAC:
6
LHS:
RHS:
2
Role
Role
identifier = id
identifier = id refcount = 1 3 4 1
5
Role
Role
identifier = id
identifier = id
1
Figure 4: Generated Environment for Labyrinth. NAC:
2
Role
Next section shows some of the generated TGGs for Labyrinth.
identifier = id refcount = n
LHS:
2
RHS: Role
identifier = id refcount = n
identifier = id refcount = n+1
6
3
7 8
4.1
Consistency
As we explained in subsection 3.1, an automatic coherency mechanism among the views is supplied by the tool. With this purpose a consistency relation is automatically generated between each view in the meta-model and the repository view. These relations contain TGGs that glue the different view models in a unique repository model. When the user modifies some view model, she is asked for the execution of the pertinent TGGs. These contain a set of triple rules for each concrete class and relationship in the view meta-model, handling each possible user action (creation, edition and deletion of graphical objects). As an example we next show the automatically generated rules for class Role. The triple rules (see Figures 5, 6 and 7) always relate repository model elements (depicted in the upper area of rules), with some view model elements (lower area), through a correspondence graph (intermediate area).
2
Role
4 1
1
5
Role
Role
Role
identifier = id
identifier = id
identifier = id
1
Figure 5: Creation rules for class Role.
Figure 6 shows the generated rules for handling edition of Role instances in view models. The first rule propagates the value of some role attribute from a view model to the repository model, if they are different. The second rule belongs to a different TGG, placed in a relation in the opposite direction (from the repository to the views). It is executed once the previous TGG ends and propagates changes from the repository to the other views. In this way, every change on a role instance in a certain view model is automatically updated in all the views where that instance is also used. Figure 7 shows the generated rules for handling deletion of Role instances in view models. The first rule decrements “refcount” in the role of the repository, and removes its correspondence relation. The NAC checks that no
LHS:
2
RHS:
Role
LHS:
2
Role
identifier = id attribute = x
identifier = id attribute = y
3
1
identifier = id attribute = x 3
4
5
1
2
Role
3
4
5
RHS:
identifier = id attribute = x
3
4
2
Role
5
4 1
5
1
Role
Role
Role
Role
identifier = id attribute = y
identifier = id attribute = y
identifier = id attribute = y
identifier = id attribute = x
condition x!=y
condition x!=y
Figure 6: Edition rules for class Role.
instance with the same identifier is present in the view model. The second rule removes a role from the repository if its attribute “refcount” reaches 0, which means there is no instance left in any view model.
children of some team or role can execute certain function, we can move the execution permission to their parent. In this way, the rule in Figure 8 creates the corresponding permission for a certain team to execute one function if the team does not have it yet (application condition X1/Y 1), if the team has some child (application condition X2/Y 2) and all the children define the permission to be moved (application condition X3/Y 3). Then, rule in Figure 1 removes such permission from all the children. Nonetheless, the latter rule is useful by itself, since it removes redundant permissions in children nodes when they have already been defined in some parent. Y1:
X1:
1
LHS:
Team
1
RHS:
Team
permission 4
NAC:
LHS:
1
Role identifier = id refcount = n
RHS:
1
LHS:
Role
Role
identifier = id refcount = n−1
refcount = 0
1
2
RHS:
3 4
2
Function Component
Y3:
2
1
X3:
Team
composition 8
3
1
Team
Y2:
1
Team
Function Component
X2:
composition 6 7
Subject
2
Function Component
composition 8 7
5
Role
1
Team
permission 3
Subject
5
Subject
permission 9
identifier = id
2
Function Component
Figure 7: Deletion rules for class Role. Figure 8: One of the refactoring pull up rules.
4.2
Metrics and Refactoring
5 We have provided some graph grammars for Labyrinth design optimization. As an example we show some rules implementing a refactoring similar to the “pull up method” [7] [11]. This moves a method (in our case a relation) defined in all subclasses of a class to the latter. The grammar is applied to the repository, because no view contains all the classes and relationships involved in the structural optimization. The changes are afterwards propagated to the correspondent view models. In Labyrinth, roles and teams of one application are allowed to execute certain functions through a permission relationship between both (see meta-model in Figure 1). Roles and teams are nested through a composition relationship resulting in hierarchical structures. Permissions are inherited through the hierarchy of roles and teams. If all the
Related Work
To our knowledge, there are no many tools supporting the automatic generation of modelling environments with multiple views and built-in consistency mechanisms. Pounamu [13] is one of the few. Its approach is similar to ours since meta-modelling is used to define each view of a VL. Basic consistency among views is implicitly supported with no programming required. More complex constraints have to be programmed in Java by the VL designer. We think we supply a more formal approach using graph transformation with the same purpose. This has the advantage of being a graphical way to specify mappings. Moreover, the supporting theory makes transformations subject to analysis [6]. Other tools for the visual environment generation, such as the Generic Modelling Environment
(GME) [10] or GenGed [1], do not incorporate multiple views management at all. Different approaches implementing code refactoring [7] are found in the literature. For example, in [11] graph transformation is used with this purpose. In this work we use the same approach but applied to software design improvement. In addition, our transformations can be guided by metrics.
6
Conclusions
In this work, we have presented a formal approach to the automatic generation of environments for VL supporting multiple views. The approach is based on meta-modelling and graph grammar techniques. Consistency among views is achieved constructing a unique model gluing all the models defined for the different views. This unique model, called repository, is created by the execution of TGGs, automatically generated by the tool. Once a unique model is available, extra functional validations and structural improvements can be applied using regular graph grammars. This approach has been implemented in the AToM3 meta-modelling tool. As a proof of concept, we have shown a non-trivial example of an environment for the Labyrinth VL. We are currently working on integrating analysis mechanisms for graph transformation, as well as in transforming the repository model into semantic domains for functional verification.
References [1] Bardohl, R. 2002. A Visual Environment for Visual Languages. Science of Computer Programming 44, pp.: 181-203. [2] Bardohl, R., Ehrig, H., de Lara J., and Taentzer, G. 2004. Integrating Meta Modelling with Graph Transformation for Efficient Visual Language Definition and Model Manipulation. LNCS 2984, pp.: 214228. Springer. [3] de Lara, J., Vangheluwe, H. 2002. AToM3 : A Tool for Multi-Formalism
Modelling and Meta-Modelling. Proc. ETAPS/FASE’02, LNCS 2306, pp.: 174 - 188. Springer. See the AToM3 page: http://atom3.cs.mcgill.ca [4] Díaz, P., Aedo I., and Montero S. 2001. Ariadne, a development method for hypermedia. LNCS 2113, 764-774. Springer. [5] Díaz, P., Aedo I., and Panetsos F. 2001. Modeling the Dynamic Behavior of Hypermedia Applications. IEEE Transactions on Software Engineering, 27 (6). 550-572. [6] Ehrig, H., Kreowski, H.-J., Montanari, U., Rozenberg, G. (eds). 1999. Handbook of Graph Grammars and Computing by Graph Transformation. Vol 1, 2 and 3 World Scientific. [7] Fowler, M. 1999. Refactoring: Improving the Design of Existing Code. Addison Wesley. [8] Guerra, E., de Lara, J. 2003. A Framework for the Verification of UML Models. Examples using Petri Nets. Proc. JISBD’03. pp.: 325-334. Alicante. [9] Guerra, E., de Lara, J. 2004. Event-Driven Grammars: Towards the Integration of Meta-Modelling and Graph Transformation. LNCS 3256, pp.: 54-69. Springer [10] Lédczi, A., Bakay, A., Marói, M., Vögyesi, P., Nordstrom, G., Sprinkle, J., Karsai, G. Composing Domain-Specific Design Environments. IEEE Computer, Nov. 2001, pp.: 44-51. [11] Mens, T., Demeyer, S., Janssens, D. 2002. Formalising Behaviour Preserving Program Transformation. LNCS 2505, pp.: 286-301. Springer. [12] Schürr, A. 1994. Specification of Graph Translators with Triple Graph Grammars. LNCS 903, pp.: 151-163. Springer. [13] Zhu, N., Grundy, J.C. and Hosking, J.G., 2004. Pounamu: a meta-tool for multi-view visual language environment construction Proc. 2004 VL/HCC, pp. 254-256.
