Eliminating Crosscutting Constraints from Visual Model Transformation Steps László Lengyel
Tihamér Levendovszky
Hassan Charaf
Budapest University of Technology and Economics Goldmann György tér 3. 1111 Budapest, Hungary
Budapest University of Technology and Economics Goldmann György tér 3. 1111 Budapest, Hungary
Budapest University of Technology and Economics Goldmann György tér 3. 1111 Budapest, Hungary
[email protected]
[email protected]
[email protected]
ABSTRACT This paper presents the aspect-oriented constraint management of the Visual Control Flow Language (VCFL) applied in the Visual Modeling and Transformation System (VMTS). To define the transformation steps precisely, additional constraints must be specified beyond the structure of the visual models (such as UML models). Structural and attribute transformation methods cannot perform and express the issues, which can be addressed by constraint validation. The use of OCL as a constraint and query language in modeling is a suitable choice. In our experience, constraints are proven to be useful in model transformations as well: VCFL uses OCL constraints to define constraints on the nodes of the transformation steps and to choose between different control flow branches. Often, the same constraint is repetitiously applied in many different places in a transformation and crosscuts it. It would be beneficial to describe a common constraint in a modular manner and designate the places where it will be applied. Using an illustrative case study, this paper introduces the problem of crosscutting constraints in visual model transformation steps, and provides an aspect-oriented solution for it, applying aspectoriented constraints and constraint weaving methods. Finally, the similarities between AOP and the AO constraint concepts are also discussed.
Categories and Subject Descriptors D.2.2 [Software Engineering]: Design Tools and Techniques;
General Terms Algorithms, Design and Languages.
Keywords Aspect-Oriented Constraints, Control Flow, Constraint Weaving, Metamodel-Based Model Transformation, OCL.
1. INTRODUCTION VMTS [11] [18] is an n-layer metamodeling environment which supports editing models according to their metamodels, and allows specifying OCL constraints. Models are formalized as directed, labeled graphs. VMTS uses a simplified class diagram for its root metamodel (“visual vocabulary”).
Also, VMTS is an UML-based [13] model transformation system, which transforms models using graph rewriting techniques. Moreover, the tool facilitates the verification of the constraints specified in the transformation step during the model transformation process. Transformation steps specify the operational behavior of model processing. This technique is based on graph transformations [15]. A transformation is built from transformation steps specifying their exact execution order. In VMTS, the metamodels of the input and the output of the transformations are assumed to be available. VMTS is based on visual languages, thus, it also uses graphical notation, stereotyped UML activity diagram for the control flow. Activity diagrams are intended to describe procedural logic, business process, and work flow. The VMTS Visual Control Flow Language (VCFL) facilitates composing complex model transformations of simple transformation steps and executing them. VCFL supports sequential and parallel application of the steps, providing conditional branch expressions, hierarchical step placement, and iteration control structures in a deterministic manner. In VCFL, the transformation steps are stereotyped activities. Often, the same constraint is repetitiously applied in many different places in a transformation, therefore the constraint crosscuts the transformation steps. Aspect-Oriented Software Development (AOSD) [2] provides a technique to address separation of concerns (SoC) that are focused on crosscutting. The methods of AOSD facilitate the modularization of crosscutting concerns within a system. AOSD attempts to decompose a system further into core application concerns, and a special type of concern called a ‘crosscutting concern’. A crosscutting concern cannot easily be modularized, because the concern tends to be scattered across a system. AOSD allows crosscutting concerns to be separated from the core concerns so that they can be reasoned about in isolation and woven back later to form a functioning system. AOSD began at the programming language level of the software development life-cycle, and over the last decade several aspectoriented programming languages were introduced (e.g. AspectJ [4], HyperJ [6] and AspectC++ [3]). Aspect-oriented programming eliminates the crosscutting concerns on the programming language level, but the aspect-oriented techniques must also be applicable on a higher abstraction level. An aspect-
oriented approach is introduced in [5] for software models containing constraints, where the dominant decomposition is based upon the functional hierarchy of a physical system. This approach provides a separate module for specifying constraints and their propagation. A new type of aspect is used to provide the weaver with the necessary information to perform the propagation: the strategy aspect. Strategy aspect provides a hook that the weaver may call in order to process the node-specific constraint propagations. The motivation of the work presented in this paper is to eliminate the crosscutting constraints in visual model transformation steps. Similarly to [5] it is achieved on the modeling abstraction layer with the following difference: this approach eliminates the crosscutting constraints from software models, while our approach separates the crosscutting constraints from model transformation steps. Current approach provides the opportunity to specify constraints separately, and to automatically propagate them with a weaver algorithm to the nodes contained by the model transformation steps – referred to as pattern rule nodes (PRNs).
2. BACKGROUND AND RELATED WORK Graph rewriting [15] is a powerful technique for graph transformation with a strong mathematical background. The atoms of graph transformations are rewriting rules, each rule consists of a left-hand side graph (LHS) and right-hand side graph (RHS). Applying a graph rewriting rule means finding an isomorphic occurrence (match) of LHS in the graph the rule being applied to (host graph), and replacing this subgraph with RHS. Models can be considered special graphs; they simply contain nodes and edges between them. This formal background makes possible to treat models as labeled graphs and to apply graph transformation algorithms to models using graph rewriting. In the VMTS approach, LHS and RHS of the transformation steps are built from metamodel elements. This means that an instantiation of LHS must be found in the host graph instead of the isomorphic subgraph of LHS. Previous work [11] has shown that the rules can be made more relevant to software engineering models if the metamodel-based specification of the transformations allows assigning OCL constraints to the individual transformation steps. The Object Constraint Language (OCL) [12] is a formal language for analysis and design of software systems. It is a subset of the UML standard [13] that allows software developers to write constraints and queries over object models. A constraint is a restriction on one or more values of an object-oriented model or system: A precondition to an operation is a restriction that must be true just prior to execution. Similarly, a postcondition to an operation is a restriction that must be true just after its execution. There are many graph transformation system, which are based on graph rewriting rules. The GReAT framework [7] is a transformation system for domain specific languages (DSL) built on metamodeling and graph rewriting concepts. The LHS of the GReAT rules can contain OCL constraints to refine the pattern. PROGRES [14] is a visual programming language in the sense that it has a graph-oriented data model and a graphical syntax for its most important language constructs. In PROGRES the precondition and the postcondition of a transaction are queries. The Attributed Graph Grammar (AGG) [1] system is a Java-based
visual programming environment. Constraints can be specified either visually or textually. The textual constraint expressions are provided in Java. VIATRA [17] is a model transformation framework developed mainly for the formal dependability analysis of UML models. In VIATRA model constraints are graph patterns with arbitrary levels of negation.
3. PROBLEM STATEMENT In model transformation, the dominant decomposition is the functional behavior of the transformation steps. The constraints ensure the correctness of the transformation only if they are welldefined by the designer. Although they are responsible for the correctness, the constraints are usually specified after the first draft of the transformation, and treated with secondary importance. They crosscut the transformation, and it is almost impossible for the designer to perform the intuitive steps of verifying the transformation. In many cases not only a transformation step but a whole transformation is required to validate, preserve or guarantee a certain property. To meet this expectation, all the transformation steps have to be taken into consideration. If one defines a constraint for several transformation steps or for a whole transformation, then the same constraint appears numerous times in the transformation and crosscuts it. The modification and deletion of a crosscutting constraint is not consistent, because such an operation must be performed on all of its occurrences. Moreover, it is often difficult to reason about the effects of a complex constraint when it is scattered across the numerous pattern rule nodes in transformation steps. Assume we have a transformation which modifies the properties of the Person type objects and we would like the transformation to validate that the age of a Person is always under 200 (Person.age < 200). It is certain that the transformation preserves this property if the constraint is defined for all PRN of type Person. This means that the constraint can appear in each transformation step several times. Therefore the constraint crosscuts the whole transformation [8] [18]. The next section discusses a model transformation-based case study. It presents a transformation with 11 transformation steps and emphasizes two constraints, from which the first one appears 30 times in 11 transformation steps and the second one 16 times in 6 transformation steps. It is very difficult to manage manually these tangling constraints, because all of the modifications have to be done on all occurrences of the constraints. Constraints appearing several times in a transformation increase the time of constraint handling and the possibility of making an error during the modification. A few tangling constraints can make the whole transformation a scattered. Using aspect-oriented techniques, our motivation is to solve the problem of the crosscutting constraint in model transformations. The main idea is to handle constraints similarly to AOP aspects, to provide the transformation constraints with the properties of the AOP aspects. Our goal is to construct AO constraints, which are created separately from transformation steps and encapsulate the crosscutting concerns, and provide weaver method for AO constraint propagation. In summary, the aim is to achieve the consistent constraint management (modification, deletion and propagation) with separating crosscutting constraints, and a weaving method.
4. A CASE STUDY To show the practical relevance, the model transformation and aspect-oriented constraint management of the VCFL is a case study is provided. The case study is a variation of the ‘class model to RDBMS’ transformation (also referred to as object-relational mapping). An input model, as shown in Fig. 1, consists of classes and directed associations. A class, which could be persistent or non-persistent, consists of one or more attributes, from which at least one must be primary key. An attribute type is either that of another user class, or that of a primitive data type. Classes that are marked as persistent in the source model should be transformed into a single table. Classes that are marked as non-persistent should be transformed into the tables of the persistent classes that they are connected to. Attributes whose type is a primitive data type should be transformed to a single column. Attributes whose type is a persistent class should be transformed to one or more columns, which should be created from the primary key attributes of the persistent classes. The primary keys and foreign keys of the translated non-persistent class need to be merged appropriately, taking into consideration that the translated non-persistent class may contain primary and foreign keys from an arbitrary number of other translated classes.
new columns and foreign keys to it, based on the adjacent persistent and non-persistent classes.
Figure 2. The output model of the transformation. The two loops composed of the AddNonPersHelperEdge, ProcessNonPersClass, AddFKeyHelperEdge, ShiftNonPersHelperEdge, ShiftNonPersHelperEdge2, DeleteNonPersHelperEdge steps process the non-persistent class chains. The AddNonPersHelperEdge step (bottom of Fig. 4) matches a non-processed persistent class (PersistentClass) with its created table (Table) along with its adjacent non-persistent classes (NonPersistentClass), and adds helper edges (nonPersHelperEdge) to connect them. The transformation uses these helper edges to identify the next non-persistent classes.
Figure 1. An input model of the transformation. An expected RDBMS output model is depicted in Fig. 2 for our sample input model. It consists of one or more tables. A table consists of one or more columns. One or more of these columns will be included in the pkey slot, denoting that the column forms part of the table’s primary key slot. A table may also contain zero or more foreign keys. In this paper, we concentrate on the issues related to the crosscutting constraints. The detailed description of the objectrelational mapping can be found in [16] and its VCFL solution (transformation steps, constraints) is available in [18]. The VCFL control flow model (transformation) for the case study is depicted in Fig. 3. The CreateTables step is executed exhaustively. As long as there is a proper match in the input model, the step creates tables, columns, and public keys, based on the persistent classes and their attributes. Furthermore, this step links each persistent class with a helper edge (classTableHelperEdge) to the corresponding created table. Using this helper edge, the steps executing after the CreateTables step can reach the appropriate table from the persistent class to add
The non-persistent class chain could consist of optional number of classes and the transformation must traverse and concatenate the names of the classes contained by the chain to create the table columns with these names. Therefore, the ProcessNonPersClass step stores the actual prefix of the table names created from the non-persistent class names in the helper edges. These helper edges always point to the actual non-persistent classes being processed. The matching is performed not only based on the structure but it must be checked that the matched class is non-processed, persistent, and its neighbors are non-persistent classes. Dealing with OCL constraints provides a solution for this issue, whereas it cannot be address by structural and attribute transformation methods. The matched but non-processed persistent class is the actual persistent class in this loop. If the step was successful (there was an appropriate match and the rewriting was completed successfully), the decision object selects the branch pointing to the ProcessNonPersClass step, otherwise it selects CreateFKeysFromNeighbours. The decision object makes the decision according to the SystemLastRuleSucceed system variable, which contains the result of the previous step execution. The ProcessNonPersClass uses the nonPersHelperEdges to transform the attributes of the pointed non-persistent classes to columns and public keys. If the next class in the chain is a persistent class the AddFKeyHelperEdge step links it with an fkeyHelperEdges to the actual persistent class. Otherwise, if the
next class is also non-persistent, then the two ShiftNonPersHelperEdge steps shift the nonPersHelperEdges from the already processed non-persistent classes to their adjacent non-persistent classes. If the helper edge is successfully shifted, the next decision object – also according to the value of the SystemLastRuleSucceed variable – selects the branch to the ProcessNonPersClass step.
steps. As it is mentioned above we use the OCL constraint called PersistentClass (context Class inv PersistentClass: self.is_persistent = 1) 30 times and the constraint NonPersistentClass (context Class inv NonPersistentClass: self.is_persistent = 0) 16 times in the transformation. In model transformation, the OCL constraints assigned to the PRNs represent the crosscutting concerns.
When all non-persistent classes in the current chain are processed, the branch to the DeleteNonPersHelperEdge step is selected. This step removes the nonPersHelperEdges and modifies the is_processed property of the actual persistent class to true. As a result of this property modification, the AddNonPersHelperEdge step will not match the already processed persistent classes again. If all the non-persistent class chains that are connected to the persistent classes are transformed to columns and public keys, the AddNonPersHelperEdge step does not find a match and the decision object selects the branch pointing to the CreateFKeysFromNeighbours step.
In VCFL the context information of the aspect-oriented constraints is a type-based pointcut – it selects the PRNs based on their metatype. In VCFL the weaving process driven by the typebased pointcuts is called type-based weaving. In the case study the Class is the type (context) of the PersistentClass constraint and the PRNs the constraint propagated to are selected based on their metatype. A weaving constraint is similar to a property-based pointcut, it is also an OCL constraint, which specifies the weaving but it is not used in the transformation steps. Weaving constraints facilitate optional conditions during the weaving process. Therefore in VCFL it is referred to as constraint-based weaving. A weaving constraint can be used to represent one or many characters as a means of specifying more than one attribute during a search procedure. This enables to select multiple PRNs with a single specification. In the case study we use weaving constraints to refine the conditions expressed by the AO constraints. AO constraints are constrains defined separately from the steps and woven to the steps later. The PersistentClass AO constraint is used with the following weaving constraint. self.name = ‘PersistentClass*’
Figure 3. The VCFL control flow model (transformation) of the case study. The CreateFKeysFromNeighbours, CreateFKeysFromHelpers, DeleteFKeyHelperEdges and DeletTableHelperEdges steps are executed exhaustively. The first two steps create the foreign key relations based on the primary keys of the adjacent persistent classes and fkeyHelperEdge temporary edges created by the AddFKeyHelperEdge step. Finally, the last two steps remove the fkeyHelperEdge and classTableHelperEdge helper edges. The interface of the transformation steps allows the output of one step to be the input of another step, in a dataflow-like manner. This is used to sequence the execution of the expressions. In VCFL this construction is referred to as external causality. An external causality is a link between a node contained by the RHS of the ith step, and a node contained by LHS of the i+1th step. This feature accelerates the matching and reduces the complexity, because the ith step provides partial match to the i+1th step. In our case study we use external causalities to pass the actual persistent class and its table in the loop from AddNonPersHelperEdge step to DeleteNonPersHelperEdge step.
5. ASPECT-ORIENTED CONSTRAINT MANAGEMENT Based on a case study, the crosscutting concerns can be observed with respect to the constraints attached to the transformation
The asterisk (*) is a wild card that stands for any combination of letters. The PersistentClass AO constraint queries the PRNs with the type Class and from the result the presented weaving constraint selects the appropriate PRNs based on their name. A Weaving Constraint is a property-based VCFL pointcut. A weaving constraint can select optional number of PRNs based on their attribute values. In this work the corresponding VCFL constructs of the AOP aspects, join-points and pointcuts have already been discussed, but an important AspectJ element, the advice, has not been mentioned yet. In AspectJ, advice is used to define additional code that runs at join points. Table 1 summarizes the correspondence between the AspectJ and AO Constraint concepts presented in this work. Table 1. The correspondence between the AOP and AO Constraint handling concepts AOP Join-point Pointcut (name-based, property-based)
AO Step Constraints Pattern Rule Node (PRN)
Advice (before, after)
Context of the OCL Constraint (type-based), Weaving Constraint (property-based) Pre- and postconditions
Aspect
AO Constraint
Having separated the constraints from the PRNs, we also need a weaver which facilitates the propagation (linking) of constraints to PRNs. Our approach solves the propagation with the Global Constraint Weaver (GCW) algorithm. The GCW algorithm is passed a transformation with an optional number of
transformation steps and a constraint list (AO constraints and weaving constraints). The algorithm propagates the AO constraints to the appropriate PRNs contained by the transformation steps. The weaving process of the GCW algorithm is presented in Fig. 4. This method facilitates our approach toward managing constraints using AO techniques [8]. Similarly to aspects, the constraints are specified and stored independently of any model transformation step or PRN and are linked to the PRNs by the GCW. In Fig. 4 the AddNonPersHelperEdge step is the input step of the GCW algorithm. Recall that this step matches a persistent class that is non-processed yet along with its adjacent non-persistent classes and adds helper edges (nonPersHelperEdge) which connect them. The transformation uses these helper edges to process the pointed non-persistent classes. The step must distinguish between the persistent and non-persistent classes to be able to match the nodes correctly, thus, the PersistentClass and NonPersistentClass constraints are propagated to it. The inputs of the GCW are the transformation step, AO constraints and the weaving constraints. The output is the constrained transformation step. The PRNs of the step, both on LHS and RHS, are the PersistentClass, the NonPersistentClass and the Table nodes.
of the transformation step is suitable for a constraint if starting from the PRN to which the constraint is linked, one can traverse the paths described by the navigation paths of the constraint. In other words the pattern of the transformation step contains nodes with an appropriate type, and relation between them which facilitates to traverse the navigation paths contained by the constraint. (iii) In the third step, examining the transformation steps, the algorithm decides if it is necessary to assign a constraint to each transformation step, or it is sufficient to assign it only to the first step as a precondition, and to the last step as a postcondition. If an intermediate state modifies one of the properties contained by the constraint, the algorithm assigns the constraint to this intermediate state to prevent a violated condition not being revealed until the end of the transformation. The pseudo code of the GCW algorithm is as follows. GLOBALCONSTRAINTWEAVING(Constraint[] Cs, Transformation T) 1 foreach Constraint C in Cs 2 foreach Transformation Step S in T 3 nodesWithProperMetaType = METATYPEBASEDSEARCHING(ContextInfo of C, S) 4 nodesToCheck = CHECKSTRUCTURE (nodesWithProperMetaType, S, C) 5 if (ISREQUIREDTOWEAVE(C, nodesToCheck, out nodesToWeave, true)) then 6 WEAVECONSTRAINT(C, nodesToWeave ) 7 endif 8 end foreach 9 end foreach
Another example for transformations and the need for aspectoriented constraint management are discussed in [9]. With the help of a case study it is presented how VMTS generates source code for a mobile platform from a resource model and a statechart diagram, applying graph-rewriting-based transformation methods. Furthermore, it is depicted how it validates specific properties using the OCL constraints enlisted in the transformation steps. The goal of the method was that if the statechart is specified in detail, then the generated code will handle the user interface described by the resource model. The input of the case study is a resource model which contains the necessary user controls and describes the user interface and a statechart diagram which represents the operation of the resource model. The models describe the resource and the operation of the Cinema Ticket application, which is used on mobile platform to order cinema tickets using a cellular phone.
Figure 4. The Weaving process and the input and the output of the Global Constraint Weaver algorithm. The GCW algorithm has three main steps to select the PRNs to which the constraint must be linked. (i) It obtains the PRNs from the transformation steps with a metatype corresponding to the context information of the AO constraint. Furthermore, it queries other properties needed to check the weaving constraints. (ii) If the constraint contains navigation steps (e.g. Class.table.name = ‘Order’), then the algorithm checks the structure of the transformation step for each previously selected PRN whether it satisfies the pattern required by the navigation paths. The pattern
From the statechart diagram, VMTS generates a model which represents the source code of the event handlers independent from any programming language. The resource model is also transformed into another model which describes an XML file, and contains all information related to the user interface. From these models VMTS can generate user interface handler code for mobile platform. We require from steps to match only those user controls which do not have a generated XML model, and statechart states which do not have a generated source code model. To achieve these conditions we use OCL constraints which appear numerous times in the transformation steps. Therefore the open issue with respect to the transformation is that the same constraints appear several times and crosscut the steps. The problem is solved with aspectoriented constraint management.
6. CONCLUSIONS
8. REFERENCES
We have found that the source of our transformation problems is often related to the lack of support for modularizing crosscutting concerns. As we have extended our metamodel-based visual transformation language with an aspect-oriented constraint management approach, it was observed that the maintainability and understandability of our transformation steps have been increased along with the attached constraints. Considering the correctness of the transformation, the understandability of the constraints is crucial, since the verification is still left to the intuition and the experience of the designer. In this paper, we presented the problem of the crosscutting constraints in the transformations together with a case study. For the open issue an aspect-oriented solution has been provided. Furthermore, the concept of the aspect-oriented constraints and weaving constraints are introduced, and similarities between the AOP and the AO constraint management were discussed.
[1] The Attributed Graph Grammar System (AGG) Homepage, http://tfs.cs.tu-berlin.de/agg
Using AO constraints in metamodel-based model transformations we achieved several benefits. Consistent constraint modification and simple constraint removal became possible. The same constraint does not appear repetitiously in many different places. Moreover, it is not necessary for the transformation steps to be aware of the constraints, nor for the modeler who creates the transformation steps. Transformation steps are applicable with or without constraints. These methods have successfully been applied in industrial projects, like generating user interface from resource model and user interface handler code from statechart model for Symbian [9] and .NET Compact Framework mobile platform [10]. The introduced approach can be generalized to other transformation languages which facilitate to assign constraints to transformation steps. The presented concepts and algorithms can be reused with minor, approach related modifications. The main limitation of the aspect-oriented constraint management is that it requires more preprocessing steps than the general approach. We have to define the constraints and transformation steps separately, and then the propagation of the constraints to the transformation steps must be performed automatically, which, obviously, takes time. This overhead can be expressed as follow. The computational GLOBALCONSTRAINTWEAVER c
complexity algorithm
is
of at
the most
s
Ο(∑∑ (lg vr + nij * v rh + nij )) , where vr denotes the number i =1 j =1
of the nodes in the actual transformation and lg vr is the complexity of querying a node from the database. The variable c denotes the number of the constraints to be propagated to the transformation steps, s is the number of the transformation steps in the transformation. More over, nij is the number of the nodes in the jth transformation step with the same type as the context of the ith constraint. (In this case the vrh is the worst case for isomorphism [15], where k is the size of the subgraph.)
7. ACKNOWLEDGMENTS The fund of “Mobile2004 Consortium” has supported, in part, the activities described in this paper.
[2] AOSD Homepage, http://www.aosd.net/ [3] AspectC++, Hhttp://www.aspectc.org/ [4] The AspectJ Programming Guide, http://www.aspectj.org [5] Jeff Gray, Ted Bapty, Sandeep Neema, and James Tuck, Handling Crosscutting Constraints in Domain-Specific Modeling, Communications of the ACM, October 2001, pp. 87-93. [6] HyperJ, http://www.research.ibm.com/hyperspace/HyperJ/ HyperJ.htm [7] G. Karsai, A. Agrawal, F. Shi, J. Sprinkle, On the Use of Graph Transformation in the Formal Specification of Model Interpreters, Journal of Universal Computer Science, Special issue on Formal Specification of CBS, 2003. [8] L. Lengyel, T. Levendovszky, H. Charaf, Weaving Crosscutting Constraints in Metamodel-Based Transformation Rules, 8th International Conference on Information Systems Implementation and Modeling, ISIM ’05, April 19-20, 2005, Czech Republic, pp. 119-126. [9] L. Lengyel, T. Levendovszky, G. Mezei, B. Forstner, H. Charaf, Metamodel-Based Model Transformation with Aspect-Oriented Constraints, International Workshop on Graph and Model Transformation, GraMoT, Tallinn, Estonia, September 28, 2005, to be published. [10] L. Lengyel, T. Levendovszky, H. Charaf, Implementing an OCL Compiler for .NET, In Proceedings of the 3rd International Conference on .NET Technologies, Pilsen, Czech Republic, May-June 2005, pp. 121-130. [11] T. Levendovszky, L. Lengyel, G. Mezei, H. Charaf, A Systematic Approach to Metamodeling Environments and Model Transformation Systems in VMTS, Electronic Notes in Theoretical Computer Science, International Workshop on Graph-Based Tools (GraBaTs) Rome, 2004. [12] OMG Object Constraint Language Specification (OCL), http://www.omg.org [13] OMG UML 2.0 Specifications, http://www.omg.org/uml/ [14] PROGRES system can be downloaded from http://wwwi3.informatik.rwthaachen.de/research/projects/progres/main.html [15] G. Rozenberg (ed.), Handbook on Graph Grammars and Computing by Graph Transformation: Foundations, Vol.1 World Scientific, Singapore, 1997. [16] http://sosym.dcs.kcl.ac.uk/events/mtip/long_cfp.pdf [17] D. Varró and A. Pataricza, VPM: A visual, precise and multilevel metamodeling framework for describing mathematical domains and UML, Journal of Software and Systems Modeling, 2003 [18] The VMTS Homepage. http://avalon.aut.bme.hu/~tihamer/research/vmts
