TGGs for Transforming UML to CSP: Contribution to the ACTIVE 2007 Graph Transformation Tools Contest. Technical Report tr-ri

Transcription

1 TGGs for Transforming UML to CSP: Contribution to the ACTIVE 2007 Graph Transformation Tools Contest Technical Report tr-ri Joel Greenyer, Jan Rieke, and Oleg Travkin Department of Computer Science University of Paderborn D Paderborn Germany [jgreen jrieke Ekkart Kindler Informatics and Mathematical Modelling Technical University of Denmark (DTU) DK-2800 Kgs. Lyngby Denmark January 2008 Abstract Along with the AGTIVE 2007 conference, a Graph Transformation Tools Contest invited tool implementers to present their solutions in order to compare the principles and particular strengths and weaknesses of today s graph transformation tools. This paper documents our contribution to the Tools Contest. The second transformation problem, a transformation from UML activity diagrams to CSP processes, i. e. a transformation between two models, is a typical application for Triple Graph Grammars (TGGs). We present our solution, including the TGG rules and the implementation of our TGG interpreter. Moreover, we point out the advantages of our solution as well as some restrictions of the current implementation. This paper only briefly states the transformation problem (the details can be found in the paper by the contest organizers [1]) and focuses on our TGG approach and the discussion of the rules. For a general and detailed discussion of TGGs, we refer to [5].

2 ii

3 1 1 Introduction Triple Graph Grammars (TGGs) allow to define the relation between two models in a descriptive way. TGGs have been defined by Schürr [7] where the models where represented as graphs. In the original version of TGGs, all nodes had the same type and nodes had no attributes. But, these initial limitations have been overcome in many extensions of TGGs. The main advantage of TGGs is that the relation between two models is defined in a descriptive, rule-based way. These rules can then be used for different purposes: transforming one model into an other (in both directions), integrating two existing models and showing the relations between them, and synchronizing models (meaning that the relation between the two models is maintained whenever a change is made to one of them). The benefit is that there is a single set of rules for all these application scenarios. Today, there are different tools which take a set of TGG rules and then perform these tasks. Some translate the TGG rules to program code, which is then executed in order to perform the task; we call these approaches compiled approaches. Other tools simply take the rules and interpret them; we call these approaches interpreted approaches. Here, we cannot go into the details of the different extensions of TGGs, the different approaches, and the different tools. For an overview of the idea, the purpose, the underlying concepts, and the tools for TGGs, we refer to [5]. The AGTIVE 2007 Tool Contest 1 consists of three different tasks. The second task is a transformation from UML activity diagrams to CSP processes. Though this task does not require transformations in both directions or integration or synchronization of models, where TGGs are at their best, this transformation task can be easily achieved by TGGs. Moreover, we show that the rules are quite simple and closely related to the informal presentation of the transformation in the task definition [1]. In our contribution to the contest, we use a TGG interpreter, which was first developed within a student project at Paderborn University [2, 6] and based on that experience reimplemented in a masters thesis [3]. Though it is in a stable state, we are still improving and extending it (governed by some principles discussed in [5, 4]). Maybe, one of the main advantages of this TGG interpreter is that it is based on Eclipse 2 and, in particular, the EMF technology. This means that the meta model for the two involved models can be standard EMF, resp. Ecore models. Since Ecore is now widely used, this should make it easy for a large group of people (who are using Eclipse/EMF anyway) to use our TGG interpreter for there transformation tasks. This paper is organized as follows. In Section 2, we introduce the meta models of UML activity diagrams and CSP and explain and justify some minor changes which we made to the meta models as presented in original problem definition of the AGTIVE 2007 Tool contest. In Section 3, we introduce the relation between the activity diagram and the CSP models and show how this relation can be expressed with TGG rules. We conclude the paper with a 1 See 2 For information on Eclipse, we refer to the Eclipse web pages:

4 2 2 THE META MODELS discussion in Section 4. Appendix A contains some brief instructions how to download and set up the tool environment and how to start the transformation. 2 The meta models In our solution, we use the meta models as they were presented in the task definition [1]. For technical reasons, we introduced some minor changes which are discussed and justified below. 2.1 Activity diagrams Figure 1 shows the meta model for UML activity diagrams. It shows that an ActivityDiagram consists of ActivityEdges and of ActivityNodes. We furthermore distinguish seven different kinds of ActivityNodes: InitialNode, Action, ForkNode, etc. These are represented as classes derived from ActivityNode. Figure 1: The meta model for activity diagrams Except for the newly introduced class ActivityDiagram, this is exactly the meta model as presented in [1]. We introduced the this additional class for the following reasons: First of all, a meta model for activity diagrams should explicitly show this concept. But, more importantly, EMF needs a so-called root object from which all objects of some diagram are reachable by compositions 3 ; 3 A composition relationship has some special technical implications in EMF and is called a containment in EMF terms.

5 2.2 CSP processes 3 that is why we also introduced the composition relation to the edges and nodes. An example of how a simple activity diagram is represented according to this meta model is shown in Figure 2. On the left-hand side, we see the graphical representation of an activity diagram in so-called concrete syntax. On the righthand side, we see the same diagram in its abstract syntax, represented as an UML object diagram. Activity Diagram :ActivityDiagram break MOVE HOLD :InitialNode source :ActivityEdge name= MOVE target :Action name= break source :ActivityEdge name= HOLD target :FinalNode Figure 2: A simple activity diagram and the corresponding abstract syntax The activity diagram has two ActivityEdges which connect an InitialNode with an Action and an Action with a FinalNode. The action is simply called break here and the two ActivityEdges are labeled with MOVE and HOLD. The attribute values are reflected accordingly in the object diagram. 2.2 CSP processes This CSP meta model describes the format of a abstract syntax tree for textual CSP documents rather than describing actual CSP models. To explain this, let us first have a look at small example CSP process and its corresponding abstract syntax object diagram shown in Figure 3. CSP Document :CSPContainer :ProcessAssignment :ProcessAssignment MOVE = break -> HOLD HOLD = accel -> MOVE processidentifier :Process name= MOVE process :Prefix processidentifier :Process name= HOLD process :Prefix event targetprocess event targetprocess :Event name= break :Process name= HOLD :Event name= accel :Process name= MOVE Figure 3: A CSP process description and the corresponding abstract syntax On the left-hand side, we see a short process description of some system. In CSP terms, MOVE and HOLD represent processes of a system, and break and accel are events which can occur in this system. The expression break HOLD, pronounced break then HOLD says that if the event break occurs, the system behaves as described by the process HOLD. This expression is called a prefix expression and, here, describes what happens in the MOVE process. So the process assignment MOVE=break HOLD means that the system has a process

6 4 2 THE META MODELS MOVE, in which the event break can occur and then the system behaves as described by the process HOLD. The object diagram on the right-hand side of Figure 3 represents the abstract syntax of these expressions: A CSPContainer, representing the CSP document, contains the two ProcessAssignments. Each ProcessAssignment assigns a Prefix expression to a Process. The Prefix expression consists of the Event and another Process. Now note that the two processes MOVE and HOLD occur twice in the process assignments and occur twice as well in the abstract syntax diagram. Their identity is implied by the equality of the name attribute. Thus, the CSP model here closely resembles the textual syntax and is therefore a model for the abstract syntax tree of the textual notation. But, if we want to use this model in a tool which performs some tasks with a given CSP specification, an analysis of all occurrences of semantically identical process objects would be necessary. Therefore, a more application friendly model would have only one instance for each process of a CSP specification. For clarity, we refer to Process instances as process variables from now on. However, we do not want to deviate from the given task, but take a look at the CSP meta model in Figure 4. In contrast to the meta model for activity diagrams, the CSP meta model has a class for the root element already, Csp- Container. This container contains a set of ProcessAssignments. The left-hand side of the assignment statement is the defined process (processidentifier) and the right-hand side refers to a ProcessExpression (process). The process expression can be one of the CSP expressions: A Prefix expression (as we have seen in Figure 3), a Condition or Concurrency expression, or a SKIP expression. All these expressions are explained in more detail shortly in Section 3. Figure 4: The meta model for CSP processes

7 2.3 Correspondence nodes 5 The meta model shown here differs from the meta model given by the task description only in the following two points: First, we added Skip as a possible construct of a ProcessExpression, which was obviously forgotten in the task definition. Second, we added an association from CspContainer to Process called initial. The reason for this is that in the task definition, the activity diagram is translated to a set of processes; but, it is not clear where to start. The additional association now refers to this Process explicitly to represent the system s initial behavior. 2.3 Correspondence nodes When defining the relation between activity diagrams and CSP processes, we establish the relation by additional nodes that refer to elements of both diagrams. These nodes are called correspondence nodes. The exact meaning becomes clearer when we see the rules for defining the relation in Section 3. For sake of completeness, however, we define the types of possible correspondence nodes in Figure 5. Figure 5: The meta model for correspondence nodes Note that these classes have associations to the classes of both models, which are not shown in this diagram. 3 Defining the relation - the TGG rules In this section, we define the actual relation between activity diagrams and CSP processes. Again, we follow the lines of the task description (Sect. 3 of [1]) with some minor deviations which we believe make the relation clearer. We explain the meaning of the TGGs along with presenting them.

8 6 3 DEFINING THE RELATION - THE TGG RULES 3.1 The axiom The most trivial relation between an activity diagram and a CSP process description is that an ActivityDiagram corresponds to a CSPContainer, that is, the two root objects correspond to each other. This is also the starting point of every transformation and, thus, also is called the axiom in TGGs. This axiom is shown in Figure 6. On the left-hand side, it shows an root object of an activity diagram; on the right-hand side, it shows an root object of a CSP process, and in the middle part it shows a correspondence node relating the two. Since sides or positions in a diagram have no meaning, the domain to which the different nodes belong to are explicitly associated with a node defining the domain to which it belongs. We have the domain activity for the objects of an activity diagram and the domain csp for the CSP processes; in addition, we have the domain for the correspondence objects. Figure 6: The axiom Starting from this axiom, we now discuss the further constructs occurring in activity diagrams and show how the corresponding statements are created in the CSP process accordingly Edges The basic idea of the transformation in [1] is that every edge of an activity diagram is translated to a process assignment and for the corresponding process variable (which appears in front of the assignment symbol). The actual expression assigned to the process variable depends on the node to which the edge points and will be filled in by other rules later. This idea is shown in Figure 7. On the left-hand side, it shows an edge of the diagram; the right-hand side shows A A =. Figure 7: Idea: Transforming an edge the corresponding equation in CSP where the right-hand side of the equation is still left open as indicated by the dot. This part of the equation will be filled 4 Actually, we present these rules from the transformation point of view, since this was the task; in general TGGs do not need this direction since they work in both directions (see [5] for more details).

9 3.3 Initial node 7 in by other rules later. Now, we assume that this edge was just added to the activity diagram, which is indicated by the green color and the additional label ; we also indicate, on the right-hand side, that the corresponding equation must be added to the CSP part. This idea can be expressed by a TGG rule which is shown in Figure 8. This is not more than a translation of the informal rule from Figure 7, converting the concrete syntax to the abstract syntax according to the meta models for activity diagrams and CSP processes. On the top, it shows a corresponding Figure 8: TGG rule for an edge pair of an activity diagram and a CSP container, which are supposed to exist already. Therefore, they are shown as black context nodes (and are not labeled with ). Below that, it shows the newly added parts, indicated in green and labeled with : For the domain activity, this is the ActivityEdge, for the domain csp, it is the new ProcessAssignment with the corresponding process for the left-hand side of the assignment. Moreover, there is a new correspondence node as a manifestation of the relation between these concepts. The node with the rounded edges is an additional constraint which guarantees that the values for both name attributes of the edge and the process variable are the same. 3.3 Initial node Next, we deal with the rules for nodes. We start with the rule for the InitialNode. Figure 9 shows the idea of this transformation. We assume that the edge exists already (shown in black) and now the initial node is added as the edge s source node (shown in green and labeled with ). In that case, we mark the corresponding process variable as the initial process 5. Figure 10 shows this idea in terms of a TGG rule. The newly inserted InitialNode corresponds to the newly introduced association initial in the CSP 5 Note that this piece of concrete syntax is our ad-hoc invention for representing the initial process; but, we explicitly added it to the meta model.

10 8 3 DEFINING THE RELATION - THE TGG RULES A A Figure 9: Idea: Transforming the initial node part. Again, we add a correspondence node that keeps track of the relation of these two parts of both models. Figure 10: TGG rule for the initial node 3.4 Actions The idea for transforming an action is very similar. It is shown in Figure 11. We assume that edges A and B are there already and now an action is added between them (again shown in green and labeled with ). Now, we can give the right-hand side of the process assignment for process A, which is a prefix expression of the action followed by the process for B (formalized as a CSP prefix expression). This is shown on the right-hand side. Since this part is to be added, it is indicated in green and labeled with again. The corresponding TGG rule is shown in Figure 14. On the left-hand side (in domain activity), we see the added action between the two arcs. On the right-hand side (in the csp domain), we see the a CSP prefix expression which represents the execution of the action followed by the process B (or a reference to it). This process expression is made the right-hand side of the process assignment defining process A. The two constraints in the rounded boxes guarantee that the name of the action in the activity diagram carries over to the name of the event in CSP, and the name of the edge B carries over to the process B. Note that we exploit that for every edge of the activity diagram, there is a correspondence node which has the corresponding process assignment on the

11 3.4 Actions 9 A action A = action > B B Figure 11: Idea: Transforming an action Figure 12: TGG rule for an action

12 10 3 DEFINING THE RELATION - THE TGG RULES other side. This way, we can refer to it and add the actual definition now, the right-hand side of the assignment. 3.5 Final node The idea for the transformation of the final node is shown in Figure 13. The process definition for the processes corresponding to the incoming edge will be completed by terminating it: The right-hand side of the assignment is SKIP (the process that terminates right away). This will be inserted to the process assignment for process A. A A = SKIP Figure 13: Idea: Transforming the final node The corresponding TGG rule is shown in Figure 14. Figure 14: TGG rule for the final node It could happen that a final node has more than one incoming edge. In that case, the above rule does not work. Since the final node is used as new for the first rule. In the second, it is not new anymore. Therefore, we need an additional rule which just uses a new connection of an edge to the final node and produces the corresponding assignment to SKIP for that process. This rule is shown in Figure 15. It is the same as above except that the final node is not green (not marked by anymore). Actually, there is a concept for unifying these two rules to a single one (we call this concept grey nodes). But, this is not yet fully supported by the current implementation of our TGG interpreter. Therefore, we use two rules here instead.

13 3.6 Merge node 11 Figure 15: TGG rule for additional edges to final node 3.6 Merge node The idea for the merge node is shown in Figure 16. For every incoming edge that is attached to it, we introduce an assignment which assigns the process corresponding to the outgoing edge to the process of the ingoing edge. A C A = C Figure 16: Idea: Transforming the merge node Figure 17 shows the corresponding TGG rule for this transformation. But, as for final nodes, a merge node can have several incoming arcs. Therefore, we need an additional rule that deals with all further arcs (when the merge node is there already). This rule is shown in Figure 18.

14 12 3 DEFINING THE RELATION - THE TGG RULES Figure 17: TGG rule for first edges to merge node Figure 18: TGG rule for additional edges to merge node

15 3.7 Decision node Decision node Figure 19 shows the general idea of the translation of a decision node. All the outgoing edges of the decision node are combined into a large CSP expression (a choice) which is becomes the right-hand side of the process assignment corresponding to the incoming edge A of the decision node. A B[x] C[y] D[else] A = B <x> ( C <y> D ) Figure 19: Idea: Transforming the decision node The problem, however, is that the number of outgoing arcs is not fixed. Therefore, we need to have rules that build the expression on the right-hand side successively. To do this, we have three rules: One for the first outgoing edge of the decision node, one for all further outgoing edges (except for the last one), and one for the last outgoing edge. Figure 20 shows the idea of these three rules. The first rule creates the left-most part of the expression, but leaves the right-hand side of the condition expression open (to be filled in by the next edge). The second rule (for all intermediate edges) fills in the open part (right-hand side) of the expression from the previous rule and constructs another condition expression within it; again the right-hand side of that new condition expression is left open. This way, for all the remaining outgoing edges, the expression is growing into an increasingly nested condition expression. For the last edge (with guard else), the rule completes the condition expression by filling in only that process into the still open right-hand side of the previous condition expression, thus marking the last of the nested condition expressions. Figures show the corresponding TGG rules. Basically, these are straight-forward translations of the rules from Figure 20. In the second and third rule, we use a stereotype ( next and last ) which makes sure that the correct rule is applied 6. Note that, in the first rule, we only have a comment (not a stereotype) because the decision node is new here. Therefore, we know by this information already that the respective edge must be the first one that we consider. 6 Note that this has no actual meaning for the semantics, but guarantees that the interpreter does not run into deadends and, therefore, avoids deadlocks and increases efficiency.

16 14 3 DEFINING THE RELATION - THE TGG RULES A B[x] A = B <x>. A X <xx> ( C <y>. ) C[y] A D[else] X <xx> D Figure 20: Idea: Transforming the decision node (details)

17 3.7 Decision node 15 Figure 21: 1. TGG rule for the decision node Figure 22: 2. TGG rule for the decision node

18 16 3 DEFINING THE RELATION - THE TGG RULES Figure 23: 3. TGG rule for the decision node

19 3.8 Fork nodes Fork nodes The rules for the fork nodes follow the same principles as the rules for the decision node. The main difference is that the CSP choice is now replaced by the CSP parallel operator. Therefore, we do not explain these rules here anymore. The three rules are shown in Figures Figure 24: 1. TGG rule for the fork node Figure 25: 2. TGG rule for the fork node

20 18 3 DEFINING THE RELATION - THE TGG RULES Figure 26: 3. TGG rule for the fork node

21 3.9 Join node Join node The rules for the join node are also similar to this idea. All the incoming edges perform a synchronization and then stop, except for one which continues with the process for the outgoing edge. This gives rise to two rules which are shown in Figures 27 and 28. Figure 27: 1. TGG rule for the join node Figure 28: 2. TGG rule for the join node

22 20 4 DISCUSSION 4 Discussion The rules and the TGG interpreter are made available online and can be installed on Eclipse. The installation is explained in more detail in Sect. A. Before coming to these very technical issues, we briefly discuss our approach and its main benefits. As shown, at least for the first rules in more detail, TGGs can be used to define a relation between two models in an intuitive way. The rules are only a more technical representation (in abstract syntax) of the rules given in the informal presentation of the problem. Termination is never a problem with TGGs, provided that every rule has at least one green part in every domain. But, it could happen that not the complete source model can be translated to the target because the source cannot be completely matched by the rules. In that case, the translation would not be correct. If we assume that there is only one initial node, and that every action node has exactly one incoming and on outgoing edge (which is not required in UML, but was required in the task description), our rules will always be able to completely match the activity diagram and the transformation will thus be correct. Actually our translation is not deterministic. This, however, is not a problem of our TGG rules, but is in the nature of the problem. E. g. for the decision node there are different expression that reflect that decision (depending on the order of the edges, a multiway choice can be translated into a combination of binary choices in many different ways). Likewise the order of processes in the parallel expression constructed for the fork node is not fixed in our rules. Since this was in the nature of the problem, we did not bother to make this deterministic. But all the generated expressions, are equivalent (following the assumption from the task description that all conditions are disjoint). The generated CSP models do not always exactly reflect the semantics of activity diagrams 7. But, again, this is not a problem of TGGs, but a problem inherent to the transformation proposed in the task definition. Since we did not want to spent our time on sophisticated semantical considerations of UML activity diagrams and CSP processes, we did not correct these problems and did not work on a semantically correct transformation. Rather, we defined the transformation as proposed in the task definition. Since we did not want to go into these semantical considerations (and we did not want to come up with just another semantics for activity diagrams) a verification that this translation is correct did not make much sense and we did not do any of that kind. The task description also mentions control mechanisms that would be used on top of a transformation mechanism. Actually, we did not need 7 When loops and forks are not properly nested, there are some problems with the transformation as proposed in the transformation task.

23 REFERENCES 21 that (except for the stereotypes) for our TGG rules; which is very much in the spirit of TGG rules, since such additional control mechanisms often spoil the benefits of TGGs (see [5] for a detailed discussion). Though TGGs work nicely on this example, we did not fully exploit the power of TGGs here, since the proposed problem was a transformation problem only. The much more important features of TGGs for integrating models or for synchronizing them don t show in this example. One other important issue is performance of the transformations. For small examples the transformation engine works reasonably well. But, we did not yet experiment with larger examples. If there should be problems with efficiency, we still have the possibility to use a compiled approach of TGGs, which typically is much faster. Moreover, our current research also investigates evaluation strategies in order to improve the performance of the TGG interpreter. This, however, is subject to future research. References [1] Dénes Bisztray, Karsten Ehrig, and Reiko Heckel. Case study: UML to CSP transformation. AGTIVE 2007 Transformation Contest, July [2] A. Gepting, J. Greenyer, E. Kindler, A. Maas, S. Munkelt, C. Pales, T. Pivl, O. Rohe, V. Rubin, M. Sanders, A. Scholand, C. Wagner, and R. Wagner. Component tools: A vision of a tool. In Proc. of the 11th Workshop on Algorithms and Tools for Petri Nets (AWPN), Technical Report tr-ri , Paderborn University, Department of Computer Science, pages 37 42, September [3] Joel Greenyer. A study of technologies for model transformation: Reconciling TGGs with QVT. Master s thesis, Department of Computer Science, University of Paderborn, July [4] Joel Greenyer and Ekkart Kindler. Reconciling TGGs with QVT. In G. Engels, B. Opdyke, D. C. Schmidt, F. Weil (eds.) Proc. of MODELS 2007, Model Driven Engineering Languages and Systems, 10 th International Conference, Nashville, USA. Lecture Notes in Computer Science 4735, pages 16 30, Springer, September [5] E. Kindler and R. Wagner. Triple graph grammars: Concepts, extensions, implementations, and application scenarios. Technical Report tr-ri , Department of Computer Science, University of Paderborn, Department of Computer Science, University of Paderborn, June [6] Ekkart Kindler, Vladimir Rubin, and Robert Wagner. An adaptable TGG interpreter for in-memory model transformation. In Proc. of FUJABA Days 2004, Darmstadt, Germany. Pages 35 38, September 2004.

24 22 REFERENCES [7] Andy Schürr. Specification of graph translators with triple graph grammars. In Ernst W. Mayr, Gunther Schmidt, and Gottfried Tinhofer, editors, Graph-Theoretic Concepts in Computer Science, 20 th International Workshop, WG 94, Herrsching, Germany, Proceedings, Lecture Notes in Computer Science 903, pages , June 1995.

25 23 A Appendix: Getting started At last, we give a brief overview on how to obtain, install, and to use our tool along with the TGG rules and some example models. A.1 Preparations Install Eclipse 3.3, GMF and all its dependencies. You can follow the tutorial at Then install the Activity2CSP feature (from the update site de/cs/ag-schaefer-static/downloads/agtive2007case-tgguml2csp/). We have prepared a few examples which you can download as a compressed Eclipse project here agtive2007case-tgguml2csp/examples.zip This project includes the set of TGG rules used for our model transformation. Import the project into your Eclipse workspace by using File Import Existing Projects into Workspace Select Archive file. A.2 Using the Examples When you open /examples/example ForkJoin.activity diagram, you can see a sample activity diagram in a visual editor 8. The diagram visualizes the model /examples/example ForkJoin.activity. When opening /examples/example ForkJoin.csp, you will see the corresponding CSP model in a CSP Tree Model Editor. This model is still empty (with the exception of the empty root model element), because it will be filled by the transformation results. In the /configuration folder you find the prepared TGG interpreter configuration files which are needed to run the transformation. Also, this is the location of the correspondence model resources which will additionally be created when the transformation result is stored. To transform an activity diagram model, for example the Example ForkJoin.activity, right-clicking on the corresponding.interpreter file (having the same file prefix) and then select TGGInterpreter Start TGGInterpreter. After the transformation is completed, save the generated CSP model. You can now open the (modified) /examples/example ForkJoin.csp with the CSP Editor. Additionally, you may transform this model file to a CSP text file by right-clicking on it, selecting the CSP export context menu action 9. A.3 Creating a new model To create a custom activity diagram model, you can simply modify one of the provided examples or create a new activity diagram model. In case you 8 The Activity Diagram Editor is neither completed nor bug-free and should only provide a more user-friendly view of the diagram. 9 You will have to refresh the folder where you generated the file in order to see it.

26 24 A APPENDIX: GETTING STARTED want to specify a new model, note that you also need to create a target CSP model resource which has a CSPContainer object as its root, but is empty otherwise. To create the new activty diagram (resp. CSP) model, click File New Other... Example EMF Model Creation Wizards Activity Model (/ Csp Model ) and select Diagram (/ Container ) as Model Object. Fill the.activity model using the tree editor or use the graphical editor (select Initialize activity diagram diagram file in the context menu). To transform the created model, you have to create a new.interpreter configuration file. Use the povided wizard: File New Other... TGG Interpreter Wizard New TGG Interpreter Configuration Wizard. First select a name for the.interpreter configuration file, then select the source model (your created activity file). On the third page select the CSP file. On the next page, select our transformation rule set at /TGG/Activity2Csp.tgg. Make sure you select only this single file. Click Next and then Refresh. Select TCorrespondenceRoot as Container and click Finish. Use the created.interpreter file as described above.