Bachelor thesis by Oliver Rohe

Institute for Computer Science 

Software Engineering Group 

Warburger Straße 100 

33098 Paderborn 

Germany 

Model Transformation by Interpreting Triple 

Graph Grammars: Evaluation and Case Study. 

Thesis to receive the degree 

”Bachelor of Computer Science” 

within the integrated course of studies 

computer science. 

by 

Oliver Rohe 

Dringenberger Str.61 

33014 Bad Driburg 

submitted to 

Dr. Ekkart Kindler 

and 

Prof. Dr. Gerd Szwillus 

Paderborn, January 2, 2006

DECLARATION 

I hereby declare that this submission is my own work and that, to the best of my knowledge and 

belief, it contains no material previously published or written by another person nor material 

which to a substantial extent has been accepted for the award of any other degree of a university 

or other institute of higher learning, except where due acknowledgement is made in the text. 

Paderborn, January 2, 2006 

Oliver Rohe

Contents 

1 Introduction 3 

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 

1.2 Goals and Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 

1.3 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 

2 Model Transformation 6 

2.1 Triple Graph Grammars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 

2.2 Interpreter Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 

3 Case Study 28 

3.1 Fujaba- TGG Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 

3.2 Eclipse/EMF TGG Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 

3.3 Mapping both models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 

4 Realization 47 

4.1 Common Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 

4.2 Problems and Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 

5 Conclusion 52 

List of figures 55 

Bibliography 56 

1

Chapter 1 

Introduction 

1.1 Motivation 

In software engineering the usage of formal methods provides all kinds of different techniques 

for the specification, design, verification, validation and development of a system, which are 

supported by a wide range of different, sometimes incompatible tools. Also, these formal 

methods very often make use of different underlying formalisms and notations, which makes 

them difficult to use because knowing them all in detail is difficult and keeping different 

formal models of the same system consistent even more. 

The model driven development (MDD) approach is addressing these problems by ensuring 

the use of standard notations and models, which are widely understood and which can be 

consistently shared and reused between different steps of the software design life cycle. 

This approach is captured by the Model Driven Architecture (MDA) [1], which is defined by 

the Object Management Group (OMG) [2] and which is a set of standards and technologies 

to decouple models and to bridge them between different modeling languages and platforms. 

Therefore, it defines platform-independent models (PIM) and its automated transformation to 

one or more platform-specific models (PSMs). 

To adapt the MDD concepts, the most difficult part is to provide models and formalisms that 

can be related to each other across the software development life cycle and the tools to ensure 

a consistent transformation from one formalism into the other. 

The ComponentTools [3] project addresses these problems by providing an infrastructure to 

ease the application, integration and transformation of different formal models. Therefore, a 

model transformation mechanism has been developed as well as an application interface to 

integrate third party tools that can directly make use of the transformed models. 

In order to transform models with different formalisms and from different sources generally, 

a defined interface was implemented to interpret a formal model as graph and then perform a 

graph transformation with triple graph grammars. 

Transforming the structure of a model instance that has an object oriented meta model is 

very similar to a graph transformation, because its object instances and references can be 

interpreted as nodes and edges. Besides, objects may also contains properties like names or 

IDs, which can be transformed as well by using attributed graphs, where a node is assigned 

one or more properties. 

3

1.2. GOALS AND METHODS 

Therefore, the underlying graph model is all important for the model transformation, since 

it must contain all the information to be transformed. It must be very general and it must 

contain the most common concepts used in a variety of existing object- oriented models, so 

that different models can be transformed correctly. 

In the project group ComponentTools [3] , a first prototype of the TGG interpreter and 

its underlying TGG model has been developed. This version successfully transforms a 

ComponentLibrary [3] model into a PetriNetKernel [4] model as well as into a PetriNetMarkupLanguage 

[5] model. 

Although the concepts of the interpreter architecture is very general, the problem is to say 

whether it is always possible to transform any given model instance into another. This is due 

to the fact that models often times are very different in their structure and the information they 

keep and it is not clear whether both can always be mapped to the graph interface appropriately 

to perform a transformation into another model. 

The question is, wether there exists some model specific features or concepts that can not be 

interpreted generally and which would need to adjust the interpreter and the graph model in order 

to perform the transformation. However, doing so whenever a single model transformation 

can not be performed is not the desired behavior. 

1.2 Goals and Methods 

The subject of this thesis is to evaluate the existing interpreter architecture and its underlying 

TGG graph model by implementing yet another example model transformation. The goal is to 

get a better understanding which requirements and features are needed to describe and to perform 

a wide range of different model transformations. Especially, it should help to understand 

what a model instance and its meta model must look like in order to apply a transformation, or 

which properties may prevent a transformation to be successful. 

The results will then be used to extend the current interpreter architecture in order to get the 

example transformation to work, although it is very important not to make the architecture 

unnecessarily complex by adding useless features, but rather to keep its concepts very clear 

and general. 

The example transformation will be performed from the Fujaba TGG model to the ComponentTools 

TGG model. The speciality is that both models are different TGG models, whereas 

the latter one is also the underlying model for the transformation itself. 

Also, for the Fujaba TGG model, there exists already a very comfortable TGG rule modeling 

editor and now the goal is to use it indirectly for the ComponentTools TGG model as well, 

by transforming the created Fujaba TGG rules into the corresponding ComponentTools TGG 

rules and format. Thus, it replaces the painfull usage of the ComponentTools TGG rule editor, 

which, although was generated automatically by the EMF framework and hence gotten for 

free, is very difficult to use and therefore very error-prone. 

Another speciality is, that the example implementation will be done in a kind of bootstrapping 

manner. Therefore, the first rule set is going to be modeled with the ComponentTools editor 

4

1.3. OVERVIEW 

by hand and then after successfully doing a transformation, the Fujaba TGG editor can be used 

to remodel the rule set. The created Fujaba model will then be transformed and the result 

can be used again as a rule input for the interpreter, to transform a Fujaba TGG model into a 

ComponentTools TGG model. 

1.3 Overview 

Chapter two explains the idea of the model transformation. Therefore, triple graph grammars 

are introduced as well as the interpreter architecture and the matching algorithm. In chapter 

three, the example model transformation will be explained. Besides, both models are presented 

and the transformation details are illustrated. In chapter four the current implementation and 

its weaknesses will be evaluated, as well as the changes and enhancements being made during 

the work of this thesis in order to get the example transformation to work. 

The fourth chapter then gives an overview and provides ideas and strategies for future work 

and research. 

5

Chapter 2 

Model Transformation 

Transforming models is a very challenging problem. The existing approaches very often 

either lack performance or generality, which means that an efficient transformation usually is 

restricted to a certain class of models, whereas general approaches usually are only applicable 

for very small input models. 

The goal of ComponentTools [3] was to ease this drawback and to be general and performant 

at once. Therefore, the idea was to interpret any in- memory model [6] as a graph and then 

perform a graph transformation using triple graph grammar rules. The following chapter will 

give an idea how, the specification and the execution of a model transformation is done. 

2.1 Triple Graph Grammars 

Triple Graph Grammars are an extension of Graph Grammars. They consist of a set of Triple 

Graph Rules to formally describe a graph transformation. A TGG rule itself consist of three 

declarative graph rewriting rules (source-, correspondence- and target- rule), whereas each 

rule again is splitted into a condition graph (left side) and an action graph (right side). 

Additionally, the correspondence rule maps source- and target- rule elements onto each other 

and therefore allows a bidirectional n:m mapping of its elements. That makes the rule applicable 

in both direction, since the correspondence mappings between the model elements always 

allow a unique identification of the elements belonging together. 

This is very benefiting, since it allows a mapping between two structurally different graphs. In 

addition, it simplifies the handling of the rules, because the correspondence structure can store 

additional information, which might be necessary for the transformation. 

Therefore, a TGG rule is nothing more than a mapping bettween the rules of two different 

graph grammars, which means that for every existing rule and its defined structural graph 

rewriting in the first grammar, there exists a corresponding graph rewriting rule in the second 

graph grammar and vice versa. In other words, whenever the node structure of a source graph 

instance allows the fireing of one of the rules from the first graph grammar, there exists a 

corresponding node structure in the target graph instance that allows the fireing of the second 

graph grammar’s rule. 

Figure 2.1 shows a simple TGG rule that was used within the context of the ComponentTools 

[3] project. It transforms a Track into its corresponding PetriNet construct. 

6

2.1. TRIPLE GRAPH GRAMMARS 

R 

L 

:Track 

source 

:Project 

:Inport 

++ 

:Outport 

2.1.1 Graph Transformation 

++ 

++ 

++ 

++ 

++ 

++ 

++ 

++ 

correspondence 

:Corresp 

:Corresp 

++ 

:Corresp 

++ 

:Corresp 

++ 

++ 

++ 

++ 

++ 

++ 

target 

:Petrinet 

++ 

:Place 

++ 

:Arc 

++ 

++ 

++ 

:Transition 

Figure 2.1 : A simple triple graph grammar rule. 

A graph transformation between two different graph instances can be performed by applying 

TGG rules stepwise. Every rule defines one transformation step, which extends the transforming 

target graph instance according to its definition on the right side of the target grammar rule 

(When the rule is read from left to right. Otherwise the right side of the source graph grammar 

rule is considered). 

The left side of the TGG rule like in the figure 2.2 defines the precondition of the transformation 

step. It shows two nodes from the source and the target grammar, mapped by a correspondence 

node. The right part of the source side defines the structure that already exists in 

the source graph instance and that needs to be transformed into the corresponding target graph 

structure. For none- deleting rules, which are currently only supported by the interpreter, the 

elements on the left side are always also on the ride side, which means that the graph is always 

only extended, but never reduced. The difficulties of handling deleting rules will be discussed 

in the chapter 5. 

R 

L 

:Track 

source correspondence target 

:Project 

:Inport 

:Outport 

:Corresp 

Figure 2.2 : Left side pre condition. 

:Petrinet 

When both, the rule’s left side and the source’s right side (L Form) can be successfully mapped 

within the graph instances, the rule can be fully applied and the target graph instance can be 

extended, as defined on the right side of the target graph grammar rule 2.3 . 

7 

++ 

++

2.2. INTERPRETER ARCHITECTURE 

L+R 

R 

:Track 


:Project :Corresp 

:Inport 

:Outport 

++ 

++ 

++ 

:Corresp 

++ 

:Corresp 

++ 

:Corresp 

++ 

++ 

++ 

++ 

++ 

++ 

:Petrinet 

++ 

:Place 

++ 

:Arc 

++ 

++ 

++ 

:Transition 

Figure 2.3 : Target right side, that needs to be created. 

Since the rule is applicable in both direction, the same principle holds, when the rule is read 

from right to left. In this case, the source graph instance is extended according to the definition 

on the right side of the source graph grammar rule. 

2.2 Interpreter Architecture 

The first prototype of the interpreter was developed during the project group ComponentTools 

[3] to support the model driven development by providing a tool that performs a well defined 

transformation of different formal models. The goal was to do the transformation generally 

and efficiently, without ever modifying the interpreter and its algorithm when a new model 

transformation has to be performed. Therefore, a graph interface was developed to allow the 

interpretation of a model instance as graph and then perform a graph transformation via triple 

graph grammars. 

The interpreter architecture that is shown in figure 2.4 is separated into four main components. 

In- 

Memory 

Model 

(Instance) 

Model 

Adapter 

Graph- 

Type 

Model 

TGG 

Interpreter 

TGG 

Rules 

Model 

Adapter 

Figure 2.4 : The interpreter architecture. 

8 

++ 

++ 

In- 

Memory 

Model 

(Instance)


1. The graph type models are referenced by the triple graph grammar rules and represent 

the meta model type definitions of the in- memory model instances. 

2. The model adapters are used as a graph interface by the interpreter to navigate on the 

in- memory model instances and its types. 

3. The TGG rule graphs describe the single transformation steps. 

4. The interpreter performes the transformation of two graphs by stepwise applying the 

TGG rules. 

Each of these components will be explained more in detail in the following sections. 

2.2.1 Graph Type Model 

The goal of the interpreter is to be independent from any model instance that has to be transformed. 

Therefore, the structure and the types of the models are hidden behind a graph interface. 

The interpreter then simply uses a model adapter (see Section 2.2.2) to virtually translate 

the model instance as graph. In order to hide the element types of a model, the interpreter uses 

a defined type interface called a graph type model. Each graph type model is equivalent to the 

actual meta model of the model instance. 

A graph type model contains node-, edge- and propertytypes, which are shown in figure 2.5 . 

* 

GraphElementType 

EdgeType 

GraphType 

+ description: String 

* 

graphTypes 

graphElementTypes 

NodeType 

+ role: String + name: String 

in 

* 

out 

* 

1 

source 

1 target 

1 

* 

PropertyType 

+ name: String 

+ type: String 

nodeType 

propertyTypes 

Figure 2.5 : A graph type and its node-, edge- and propertytypes. 

The figure 2.6 shows a graph type model that copies the meta model given as UML class 

diagram. 

Car 

color:String 

0..1 

1 

0..1 

0..* 

Engine 

Tire 

p1:PropertyType 

name=“color“ 

type=“String“ 

n1:NodeType 

name=“Car“ 

e1:EdgeType 

role=“car2engine“ 

n2:NodeType 

name=“Engine“ 

e2:EdgeType 

role=“car2tire“ 

n3:NodeType 

name=“Tire“ 

Figure 2.6 : An UML class diagram and its corresponding graph type model instance. 

9


2.2.2 Model Adapter 

The main focus of the interpreter architecture is to be usable for every possible in- memory 

model and format [6]. Therefore, an adapter interface was developed to allow the interpretation 

of a model instance as a graph. That allows the interpreter to work directly on the model 

instances, but simply uses the model adapters to virtually interpret its objects and references as 

nodes and edges. That makes it independent from its input, but still allows to manipulate any 

model instance by just calling graph interface methods declared in the model adapters shown 

in the figure 2.7 . 

public interface RealModelAdapter 

{ 

public RealModelAdapter(GraphType graphType, Object realModelInstance); 

} 

public abstract Object getRootElement(); 

public abstract NodeType getNodeType(Object object) ; 

public abstract Collection getNeighbors(Object source, EdgeType edgeType); 

public abstract Collection getAllNeighbors(Object source); 

public abstract void deleteNode(Object object); 

public abstract void deleteEdge(EdgeType edgeType, Object source, Object target); 

public abstract void getPropertyValue(Object object, String property); 

public abstract void setPropertyValue(Object object, String property, Object value); 

public abstract Object createNode(NodeType nodeType, Hashtable propertyValues) ; 

public abstract void createEdge(EdgeType edgeType, Object source, Object target); 

Figure 2.7 : The model adapter interface. 

In figure 2.7 the adapter interface methods are shown. As an example, the last method 

createEdge is used to create a new reference from an object source to an object target. 

During the method call the interpreter passes an edge type to the model adapter to let it know 

what kind of reference has to be created. The last but one method createNode creates a new 

object based on the node type parameter passed by the interpreter. An example for the usage of 

the model adapter is given in the method countNeighbors presented below 2.8 . This method 

simply counts the number of neighbor objects. 

10


Integer countNeighbors(Object source, RealModelAdapter adapter) 

1: nodeType ← adapter.getNodeType(source) 

2: outgoingEdgeTypes ← nodeType.getOutgoingEdges(source) 

3: counter ← 0 

4: while (outgoingEdgeTypes.hasNext()) do 

5: edgeType ← outgoingEdgeType.next() 

6: neighbors ← adapter.getNeighbors(edgeType) 

7: counter ← counter + neighbors.size() 

8: end while 

9: return counter 

Figure 2.8 : Example, how the interpreter interacts with the model adapter. 

Figure 2.9 shows the routine of the model adapter that returns the node type, depending 

on the objects real type. The node types are defined in the graph type meta model and will 

be loaded together with the initialization of the adapter. Below there is an extract of the method. 

NodeType getNodeType(Object object) 

1: if (object instanceof UMLProject ) then 

2: return umlprojectNodeType 

3: else if (object instanceof UMLClassDiagram ) then 

4: return umlclassdiagramNodeType 

... 

5: end if 

Figure 2.9 : Example implementation of the getNodeType routine. 

2.2.3 TGG Rule Graphs 

TGG rule graphs consists of nodes, edges and properties and they resemble object diagrams 

to clone object structures, the same as might occur in the real model instances. A TGG rule 

graph consists of three graph rewriting rules, where each rule defines the rewriting step how 

the corresponding model is to be extended. 

Additionaly, the graph elements reference the graph type models (see Figure 2.10 ). These types 

are the same as those that are used by the model adapter to translate the in- memory models for 

the interpreter. Therefore, the structure and the used object types of a TGG graph rule can be 

directly matched with the in- memory model instances to perform the transformation. 

11


Edge 

Graph 


* 

* 

GraphElement 

edge 

graph 

graphElement 

Node 

in * * 1 1 target 

out 

source 

* 

GraphElementType 

EdgeType 

GraphType 


* 

graphTypes 

graphElementTypes 

node nodetype 

edgetype 

1 

1 

1 node 

* 

Property 



properties 

NodeType 

+ role: String + name: String 

in 

* 

out 

* 

1 

source 

property propertytype 

1 target 

Figure 2.10 : The graph- and graph type- meta model. 

1 

1 

* 

PropertyType 



nodeType 

propertyTypes 

Figure 2.11 shows how the interpreter architecture interacts together. The interpreter transforms 

the model source instance. Therefore, it matches the source graph rule within the object 

structure of the source model. However, since the interpreter is supposed to be independend 

from the model instances, it must not know its structure, and its types, and therefore, the model 

adapters are used to hide both of them. The interpreter can then compare the elements of the 

rule directly with the model object instances by comparing its types. 

Real model source instance 

c1:Car eng1:Engine 

color=“Silver“ 

t1:Tire t2:Tire t3:Tire t4:Tire 

TGG source graph rule 

p1:Property 

value=“Silver“ 

n1:Node 

name=“Manta“ 

e1:Edge 

++ 

++ 

n2:Node 

name=“Continental“ 

interpreter:Interpreter 

source:RealModelAdapter 

(c1,n1) 

(eng1,n2) 

(t1,n3) 

(t2,n3) 

(t3,n3) 

(t4,n3) 

Source graph model type definition 

p1:PropertyType 

name=“color“ 

type=“String“ 

n1:NodeType 

name=“Car“ 

e1:EdgeType 

role=“car2engine“ 

n2:NodeType 

name=“Engine“ 

Figure 2.11 : A graph and the referenced model type definition. 

12 

Represents a relation. 

e2:EdgeType 

role=“car2tire“ 

n3:NodeType 

name=“Tire“


2.2.4 Interpreter 

The interpreter finally performs the model transformation by applying the TGG rules stepwise. 

Therefore, it tries to match the condition part of the TGG rule within the object structures of the 

source, target and correspondence graph. This matching is similar to the (sub) graph matching 

problem, where a smaller subgraph is searched within a bigger main graph. Before explaining 

the interpreter algorithm, firstly a short recapitulation of graph theory is given to get familiar 

with the notion again. 

2.2.4.1 (Sub-) Graph Matching 

Graphs 

A graph is defined as a tuple G = (V, E), whereas V is a set of nodes and E is a set of edges 

(see Figure 2.12 ). 

V ={v1, v2, v3}, E ={{v1, v2}, {v2, v3}, {v1, v3}} 

Directed-/Undirected Graph 

v 1 

v 2 

Figure 2.12 : A simple graph. 

Depending on the application domain a graph can be directed or undirected. Former means 

that an edge between two nodes has an explicit direction. Therefore the set of edges is defined 

as tuples of sorted nodes E ={(u, v) | u, v ∈ V }. Undirected graphs have unsorted pairs of 

nodes (see Figure 2.13 ). 

V ={v1, v2, v3}, E ={(v1, v2), (v2, v3), (v3, v1)} 

Labeled-/Attributed Graph 

v 1 

v 2 

Figure 2.13 : A directed graph. 

A graph can be labeled or attributed. That means all of its nodes and edges are labeled 

differently (but arbitrarily), so that they can be distinguished. To label the nodes and edges, a 

13 

v 3 

v 3


graph must have a labeling function which assigns every node or edge an unique id, name or 

index (see Figure 2.14 ). 

Here is an example for a graph with a node and edge labeling function. 

E = (V, E, µ, η), V ={v1, v2, v3} E ={(v1, v2), (v2, v3), (v3, v1)} 

µ : v → Lv η : e → Le 

Sub Graphs 

v 1 

A 

v 2 

C 

B 

Figure 2.14 : An attributed graph. 

A subgraph, as part of a main graph, is usually defined as a subset of the nodes and edges of 

the original graph. More formally, a graph G ′ 

= (V ′ 

, E ′ 

, µ ′ 

, η ′ 

), is a subgraph of a graph 

G = (V, E, µ, η) short G ′ 

⊆ G iff, V ′ 

⊆ V and E ′ 

⊆ E ∪ (V ′ 

× V ′ 

). Additional, the labeling 

functions must be identical. 

Morphisms between graphs 

µ(v) ′ 

� ′ 

µ(v) if v ∈ V 

= 

undefined otherwise 

A relationship between two graphs is defined as a Morphism from one graph G ′ 

to another 

graph G. 

When considering the edge relation in a graph as a binary relation, then a morphism is defined 

as a mapping function f : G ′ 

→ G such that f(u ∗ v) = f(u)αf(v), where ∗ is the relation 

on G ′ 

and α is the relation on G. That means that when there exist two nodes u, v in the 

source graph, being related by ∗, then the node images f(u), f(v) must be related by the target 

relation α as well. 

In graph theory a morphism is called a Homomorphism. 

Homomorphism 

Given two graphs, 

G ′ 

= (V ′ 

, E ′ 

), V ′ 

= {A, B, C}, E ′ 

= {(A, B), (B, C), (C, A)} 

G = (V, E), V = {D, E, F, G, H}, 

14 

v 3


E = {(D, E), (E, F ), (F, D), (F, G), (G, H), (H, F )} 

a homomorphism f between the two graphs is defined as. 

f : V ′ 

→ V such that (u, v) ∈ E ′ 

⇒ ((f(u), f(v)) ∈ E 

The figure 2.15 shows one possible homomorphism between the two graphs. 

Isomorphism 

A 

C 

B 

The arrow shows a possible node mapping. 

Figure 2.15 : A possible homomorphism f(A) = G,f(B) = H,f(C) = F 

[The word ”isomorphism” applies when two complex structures can be mapped 

onto each other, in such a way that to each part of one structure there is a corresponding 

part in the other structure...(Gdel, Escher, Bach) [7]] 

An isomorphism is a bijective (surjective and injective) mapping f between two graphs. It 

usually indicates that they are identical and that every element in the source graph can be 

mapped to an equal node in the target graph and vice versa. The definition for a sub graph 

isomorphism is given in the same way, except that a certain part of the target graph is ignored. 

It is exactly the part that doesn’t exists in the target graph. This definition for a sub graph 

isomorphism is usually very helpfull, since often times, the target graph has much more nodes 

than the source graph and one is looking for subgraphs to be identical only to a certain subpart 

of the target graph (sub graph isomorphism). Figure 2.16 shows the the four cases for different 

mapping functions. 

15 

D 

G 

F 

E 

H


1 

3 

1 

2 

2 

3 

4 

2.2.4.2 Graph Matching Algorithm 

a 

c 

a 

b 

c 

b 

(a) Bijective (injective and surjective) (b) Injective, not surjective 

1 

3 

1 

2 

2 

3 

4 

(c) Surjective, not injective (d) Not surjective, not injective 

Figure 2.16 : Mapping functions between two graphs. 

The graph isomorphism problem is very difficult to solve and not yet proven to be in either of 

the sets P or NP -Complete. However the sub graph isomorphism problem is proven to be in 

NP-Complete [8]. 

For every matching algorithm, it is almost unavoidable to try every node mapping combination 

between the two graphs. Unfortunately, this leads very quickly to a search space explosion, 

since trying every combination for two graphs G ′ 

= (V ′ 

, E ′ 

) and G = (V, E) with |V ′ 

| = m 

and |V | = n nodes causes the algorithm in worst case to try m × n! different combinations 

and therefore it runs exponentially long. 

That is by far too long for an efficient application. However, in most of the cases enough 

information exists to reduce the search space, which then results in an acceptable, quadratic 

time. These will be discussed in the following sections. 

Example 

Figure 2.17 shows an example of how to systematically try every node mapping combination. 

Starting with the first node v ′ ′ 

1 ∈ V of the source graph G ′ 

, |V | possibilities are left to match 

the node with a node vi ∈ V of graph G. When the node was matched successfully, the next 

node v ′ 

2 has |V | − 1 possibilities, to be matched and so on. 

16 

a 

b 

c 

a 

b 

d 

c 

d


n 

Node Mapping 

v' 1 

v' 2 

v' 3 

v' 4 

v' 5 

v' 5 

v' 4 

v 4 

v' 1 

v' 3 

v' 2 

v 5 

G' G 

v 3 

f(v' 1 )=v 1 

v 5 

v 4 

v 4 

v 2 

v 3 

v 4 

(1) (2) 

v 5 

v 4 

v 3 

v 1 

Figure 2.17 : Searchtree 

When a node n ′ 

from graph G ‘ does can be mapped to another node n from a graph G ? 

Depending on the underlying graph model and its graph properties there can exists many 

different criteria for equalness. However, the structure is the main property to be checked 

when two graphs are compared for equality. Therefore, the answer of the question above can 

be directly derived from the definition of a graph homomorphism in the section 2.2.4.1. It 

says, whenever there exists an edge e ′ 

between two nodes (n ′ 

1 , n′ 2 ) in graph G′ , their node 

images f(n ′ 

1 ) = n1, f(n ′ 

2 ) = n2 must be connected by an edge e in G as well. 

That means whenever the algorithm tries to match two nodes, it must check whether they have 

the same outgoing edges and hence the same neighbors. 

The following pseudocode will explain the simplified checkoutgoingEdges routine that is a 

part of the interpreter algorithm and which checks the homomorphism condition. 

As input there are two nodes n ′ 

∈ G ′ 

to be a subset of G 

... 

v 4 

v 1 

v 2 

v 4 

= (V ′ 

, E ′ 

) and n ∈ G = (V, E) whereas G ′ 

is supposed 

17 

v 5 

v 3 

n 

n-1 

n-2 

n-3 

1 

n!


boolean checkoutgoingEdges(Node n ′ 

1 , Node n1) 

1: if (n ′ 

1 .getOutgoingEdges().size() > n1.getOutgoingEdges().size()) then 

2: return false 

3: end if 

4: while (n ′ 

5: 

.getOutgoingEdges().hasNext()) do 

(e ′ 

← n ′ 

.getOutgoingEdges().next() 

6: if (isMapped(e ′ 

.getTargetNode())) then 

7: n2 ← getMappingPartner(e ′ 

.getTargetNode()) 

8: found ← false 

9: while (n1.getOutgoingEdges().hasNext() & !found) do 

10: e ← n1.getOutgoingEdges().next() 

11: if (e.getTargetNode().equals(n2)) then 

12: found ← true 

13: end if 

14: end while 

15: if (not found) then 


17: end if 

18: end if 

19: end while 

20: return true 

The checkoutgoingEdges routine simply iterates over all outgoing edges of the first node 

n ′ 

1 ∈ G′ and checks if the target node is already mapped to a node n2 ∈ G. In that case, the 

node n2 must be a neighbor node of the node n1, for which n ′ 

1 is supposed to be the mapping 

partner. 

Backtracking 

The backtracking step is a systematic approach to handle dead ends while running through 

the search space to find a solution for a given problem. During the matching application 

the algorithm traverses through both graphs G ′ 

= (V ′ 

, E ′ 

), G = (V, E), and tries every 

node mapping combination between their nodes. Whenever it ends up in a dead solution, it 

discards the last node mapping, makes one step back and proceeds with the next possible node 

mapping pair. Programmatically, a backtracking step usually is implemented as recursion. 

One backtracking step means going up one recursion step. 

Depth First Search vs. Breath First Search 

Both, Depth First- and Breath First- Search can be used to traverse a graph systematically. 

The advantage of BFS is guaranteed to find the shortest solution path first. That means using 

BFS allows the algorithm to find the smallest subgraph first, because the breadth-first strategy 

always expands all the nodes at one level of the graph before expanding any of their neighbor. 

This property is important when graphs again are subgraphs of other graphs and hence the 

interpreter could match them at once. This feature will be explained more in detail in chapter 

5. 

The default search algorithm used within the interpreter is BFS, but only a few lines of code 

would need to be changed in order let it use DFS instead. 

18


The difficulty of the matching algorithm is that it performes a BFS search on two graphs simultaneously. 

Therefore a recursive nested routine is implemented to systematicaly try every node 

matching possibility. 

The routine matchGraphs 2.19 tries to perform a graph matching between the two given 

graphs G ′ 

= (V ′ 

, E ′ 

) and G = (V, E). Therefore, it initiates the breath-first search for the 

root node mapping and then explores recursively the neighbor nodes. 

Vector matchGraphs(Graph G ′ 

, Graph G) 

1: while (V ′ 

.hasNext()) do 

2: n ′ ′ 

1 ← V .next() 

3: while (V .hasNext()) do 

4: n1 ← V .next() 

5: if (matchNodes(n ′ 

1 ,n1)) then 

6: nodeMapping ← new NodeMapping(n ′ 

1 ,n1) 

7: mappings.add(nodeMapping) 

8: edgesCopy ← n ′ 

1 .getOutgoingEdges() 

9: success ← exploreEdges(nodeMapping,edgesCopy,mappings,emptyVector) 

10: if (success) then 

11: return mappings 

12: else 

13: mappings.clear 

14: end if 

15: end if 

16: end while 

17: end while 

Figure 2.18 : This routine checks if a graph is subgraph of another graph. 

boolean matchNodes(Node n ′ 

1 ,Node n1) 

1: success ← checkoutgoingEdges(n ′ 

1 ,n1) 

2: return success 

Figure 2.19 : This routine is used to match two nodes with each other. 

19


boolean exploreEdges(NodeMapping nodeMapping, Vector edgesCopy, Vector mappings,Vector 

levelMappings) 

1: source ← nodeMapping.getSourceNode() 

2: target ← nodeMapping.getTargetNode() 

3: if (!edgesCopy.isEmpty()) then 

4: e ′ 

← edgesCopy.next() 

i 

5: n ′ 

i 

← e′ 

i .getTargetNode() 

6: while (target.getOutgoingEdges().hasNext()) do 

7: ei ← target.getOutgoingEdges().next() 

8: ni ← ei.getTargetNode() 

9: if ( isMapped(ni) & isMapped(n ′ 

i )) then 

10: oldMapping ← node2nodeMapping.get(nu) {}//node2nodeMapping is global 

map 

11: oldMapping2 ← node2nodeMapping.get(n ′ 

u) 

12: if (oldMapping.equals(oldMapping2)) then 

13: newMapping ← oldMapping 

14: end if 

15: else if (matchNodes(n ′ 

i ,ni)) then 

16: newMapping ← new NodeMapping(n ′ 

i ,ni) 

17: end if 

18: if (newMapping != null) then 

19: levelMappings.add(newMapping) 

20: mappings.add(newMapping) 

21: edgesCopy.remove(e ′ 

i ) 

22: success ← exploreEdges(nodeMapping,edgesCopy,mappings,levelMappings) 


24: return true 

25: else 

26: levelMappings.remove(newMapping) 

27: mappings.remove(newMapping) 

28: end if 

29: end if 

30: end while 


32: else 

33: while (levelMappings.hasNext()) do 

34: tmpMapping ← levelMappings.next() 

35: newEdgesCopy ← tmpMapping.getSourceNode().getOutgoingEdges() 

36: success ← exploreEdges(tmpMapping,edgesCopy,mappings,emptyVector) 

37: if (!success) then 


39: end if 

40: end while 

41: end if 

Figure 2.20 : This routine explores all outgoing edges of a node. 

The routine exploreEdges shown in the figure 2.20 simply tries to match all nodes at a given 

level by running through the outgoing edges of the actual parent node mapping’s source node 

20


and then recursively tries to find a mapping partner within the neighbor nodes of the parent 

node mapping’s target node. Once all nodes at a certain level are mapped, for each of these 

level node mappings, the routine is recursively called again. 

Graph- Rewriting/Production 

A graph may be produced by a graph grammar. Besides, its graph rewriting rules stepwise 

extends the graph according to its definition of the right side (as explained in Chapter 2.1 ). 

Therefore, the left side can be considered as a precondition subgraph, that needs to be matched 

within the existing graph in order to extend it. The matchGraph algorithm can be used to 

stepwise apply the graph rewriting rules and therefore extend the graph. 

Graph- Parsing/Derivation 

A graph that was produced by a graph grammar has been stepwise extended by the graph grammar 

rules. By deriving a produced graph back, its rule application order can be reconstructed. 

Besides, the graph rewriting rules will be virtually reapplied on the existing graph. During this 

reaplication, the graph and its elements are categorized into an already produced part and a 

virtually none- existing part. 

A rule can be successfully reaplied, whenever its precondition subgraph on the left side can 

be successfully matched within the already produced part of the graph and its right side can 

be matched within the virtually none existing part of the graph. Figure 2.21 shows a possible 

model instance and its produced elements. 

in01:Inport 

out01:Outport 

p1:Project 

t01:Track s01:Signal 

c01:Con 

in02:Inport 

out02:Outport 

Already produced 

Figure 2.21 : Nodes were already successfully reproduced 

The following rule shown in the figure 2.22 could be successfully reaplied, since its left precondition 

side can be matched within the already produced part of the graph. Therefore, 

the left side of the rule must be matched within the produced part of the model and the 

right side must be matched within the not yet produced part. A possible matching would 

be (r1,p1),(r2,in01),(r3,t01),(r4,out01). 

21


R 

L 

++ 

++ 

r3:Track 

++ 

source 

r1:Project 

++ 

r2:Inport 

++ 

r4:Outport 

Figure 2.22 : The graph rewriting rule that could be reaplied next. 

The following algorithm derives a graph back by stepwise reapplying the TGG rules on the 

graph as long as it has still not yet produced elements e.g. whenever there exists produced 

elements, that still have not yet produced neighbors. This set is called the front (see Figure 

2.23 ), since these elements mark the border between the left and the right side of a graph 

grammar rule. It is also used as starting context for possible node mappings and therefore 

helps to reduce the search space. This is because, whenever a rule is going to be matched, 

at least one of its elements on the left side must be a matching partner for at least one of the 

nodes in the front. Every time a rule is successfully matched, the front needs to be updated 

and elements get removed when they no longer have not yet produced neighbors. 

The Front 

in01:Inport 

out01:Outport 

p1:Project 

t01:Track s01:Signal 

c01:Con 

in02:Inport 

++ 

out02:Outport 

Already produced 

Figure 2.23 : The front that marks the border for the graph grammar rule’s left and right side. 

The following algorithm assumes at least one start element to be in the front. 

22


Vector deriveGraph(Vector ruleGraphs,Graph G) 

1: while (!theFront.hasNext()) //theFront is a global list do 

2: frontELement ← theFront.next() 

3: while (ruleGraphs.hasNext()) do 

4: ruleGraph ← ruleGraphs.next() 

5: nodeList ← ruleGraph.getNodes() 

6: while (nodeList.hasNext()) do 

7: node ← nodeList.next() 

8: success ← matchNodes(node,frontElement) 


10: nodeMapping ← new NodeMapping(node,frontElement) 

11: mappings.add(nodeMapping) 

12: edgesCopy ← node.outgoingEdges 

13: success ← exploreEdges(nodeMapping,edgesCopy,mappings,emptyVector) 


15: while (nodeMappings.hasNext()) do 

16: nodeMapping ← nodeMappings.next() 

17: theFront.add(nodeMapping.getSourceNode()) 

18: produced.add(nodeMapping.getSourceNode()) 

19: updateTheFront() 

20: deriveOrder.add(ruleGraph) 

21: end while 

22: else 

23: mappings.clear 

24: end if 

25: end if 

26: end while 

27: end while 

28: end while 

29: return deriveOrder 

Figure 2.24 : This routine parses a graph. 

boolean updateTheFront() 

1: while (theFront.hasNext()) do 

2: node ← theFront.next() 

3: outgoingEdges ← node.getOutgoingEdges() 

4: stayInFront ← false 

5: while (outgoingEdges.hasNext() & !stayInFront) do 

6: neighbor ← outgoingEdges.next() 

7: if (!isProduced(neighbor)) then 

8: stayInFront ← true 

9: end if 

10: end while 

11: if (!stayInFront) then 

12: theFront.remove(node) 

13: end if 

14: end while 

Figure 2.25 : This routine updates the front. 

23


In order to use the algorithm exploreEdges from above, the matchNodes routine needs to be 

changed, such that two nodes can only be matched when the first node is on the left side and 

the second node is already produced, or when the first node is only on the right side, but then 

the second node must not be produced yet. 

boolean matchNodes(Node n ′ 

1 ,Node n1) 

1: success ← (((n ′ 

1 .isLeft() & isAlreadyProduced(n1)) or (!n ′ 

1 .isLeft() & 

!isAlreadyProduced(n1))) ( & checkoutgoingEdges(n ′ 

1 ,n1)) 

2: return success 

Search space reduction 

Figure 2.26 : This routine matches two nodes. 

In order to optimize the graph matching application, the underlying graph model is very 

important. As already mentioned, the structure is one property to be checked, but there could 

be many more. For example, labled nodes and edges could be compared as well. Therefore, 

the matchNodes routine can be changed such that whenever two nodes are going to be matched 

its labels are checked first. 

success ← ((n ′ 

i .label == ni.label) & (checkoutgoingEdges(n ′ 

i ,ni)) 

Since the checkoutgoingEdges check is more expensive, the label check should be done first. 

At this point, many different properties can be checked. The more properties and the more 

restrictive the equalness of two graphs is defined, the earlier a dead end is recognized. 

Briefing 

In the above section, several graph algorithms were introduced that are almost all used within 

the interpreter algorithm that will be explained in the next chapter 2.2.4.3. The checkoutgoingEdges 

routine assures that the homomorphism condition (structure preserving) is not violated. 

The exploreEdges routine together with the matchGraph routine can be used to perform 

a graph rewriting application. The exploreEdges routine together with the deriveGraph routine 

can be used to parse a graph and reproduce its rule application order. 

2.2.4.3 Interpreter Algorithm 

The interpreter transforms two models into each other by performing a graph transformation 

with triple graph grammars. Therefore, it tries iteratively to apply the TGG rules in order to 

build up the corresponding target model. 

A TGG rule can be applied whenever its precondition can be successfully matched within 

the existing elements of the source, correspondence and target models. Depending on 

the reading direction, the precondition of the TGG rule is composed of the source graph 

grammar rule’s left and right side, the correspondence left side and the target graph grammar 

rules left side. This structure altogether is sometimes also called the L structure. The 

24


matching and the creation of the new target model elements can be divided into five main steps: 

1. Matching the source graph rewriting rule. 

2. Matching the correspondence. 

3. Matching the target graph rewriting rule’s precondition side. 

4. Extending the target model. 

5. Extending the correspondence between both models. 

R 

L 

++ 

++ 

:Track 

++ 


:Project 

++ 

1 

:Inport 

++ 

:Outport 

++ 

++ 

++ 

++ 

2 3 

:Corresp 

:Corresp 

5 

++ 

:Corresp 

++ 

:Corresp 

++ 

++ 

++ 

++ 

++ 

++ 

:Petrinet 

++ 

:Place 

++ 

:Arc 

++ 

4 

++ 

++ 

:Transition 

Figure 2.27 : The five steps of the interpreter algorithm. 

For the first step, the deriveGraph method can be used. The only difference is that, instead 

of getting a graph as input, the source in- memory model is used. However, this can be 

interpreted as a graph using the model adapter. After the interpreter has successfully matched 

the source graph grammar rule, it just needs to call the matchCorrespondence routine in step 

two, in order to go on with the TGG rule matching. 

In the second step, the correspondence between the source elements and the target elements 

needs to be checked. Therefore, the matchCorrespondence routine simply tries to map the 

correspondence nodes from the TGG rule within the real correspondence nodes between the 

source and target in- memory model that has been newly created during the transformation. 

This correspondence matching is not like a real graph matching, but rather an operation on 

data structures. Therefore, it stepwise retrieves the real correspondence nodes for all, in 

the first step, mapped source model object instances and tries to match these with the rule 

correspondence nodes. 

When a rule correspondence node could be found, the real correspondence nodes outgoing 

edges are checked within the source mappings, to make sure it is the right correspondence 

node, so far. In the next step its target outgoing edges must be mapped within the left side of 

the target graph grammar rule of the TGG rule. 

Therefore, in the third step, the matchCorrespondence runs through the outgoing edges of the 

currently treated real correspondence node and checks if their neighbor nodes (these are the 

25 

++ 

++


objects of the target in- memory model) can be matched within the left precondition structure 

of the target graph rewriting rule. For every successfull matching, a node mapping is created, 

which maps the rule node with the target in- memory model object. 

After the L structure was successfully matched, the TGG rule can be fully applied. Therefore, 

the routine doTransfomationStep runs through the nodes of the target graph grammar rule and 

creates a new object for every node that is only on the right side of the TGG rule. 

Thereafter, new edges are created by running through the same nodes to check if there exists 

edges that are only on the right side. When it does, for every of these edges, a new reference is 

created by using the nodes (mapping) partner (objects of the target model instance) as source 

object and the neighbor nodes (mapping) partner is used as target object. 

Then the interpreter can just call the model adapter method createEdge to create a new reference. 

In the last step, the newly created target elements must be mapped to its corresponding 

source elements. Therefore, the interpreter runs through the correspondence graph rewriting 

rule and creates a new node, for every rule rule node only on the right side. Additionally, 

it runs through the outgoing edges of the rule correspondence node and then retrieves the 

mapping partner object of the edge’s neighbor node, by using the global maintained map 

node2nodeMappings, which stores the current node mapping for every mapped rule node. 

Thereafter, the mapping partner (the model instance object) is stored in the newly created list, 

which will be assigned to the newly created correspondence node, using the global maintained 

map realCorrespondenceNodes2modelInstanceElements. 

Changing the Transformation Direction 

The transformation direction can be changed by calling the interpreter routine switchDirection(String 

direction). The method simply exchanges all currently maintained data structures, 

as well as the side of the model adapters, without loosing any information about the current 

transformation status. Switching the direction during the transformation is necessary when 

performing incremental transformation steps from any side of the in- memory model instances. 

Incremental Transformation 

The interpreter also supports incremental transformation steps. Although, this feature is still 

in development, it can be used for simple model changes. For this purpose, the interpreter can 

register itself as observer to the source and target model adapters and then listen for model 

changes. The adapter can send the following event types: 

• PROPERTY CHANGED 

• NEW NODE 

• NODE DELETED 

• EDGE DELETED 

The property changed event is send, when a property value was changed. 

The new node event is send, when a new object was created outside of the interpreter 

environment. Besides, the interpreter receives the newly created objects from the adapter, puts 

26


them in the front, switches the transformation direction when necessary, and simply triggers 

the transformation routine again. However, the interpreter does not restart the complete model 

transformation, but rather transforms only the newly created objects. 

The delete node event is send, when an object was deleted outside of the interpreter environment. 

Besides, the interpreter receives the deleted object from the adapter and then revokes 

the TGG rule that created this object. Therefore, it maintaines a list that stores all objects and 

references that were created within the same transformation step and maps each list entry to 

the list itself. The interpreter then deletes all objects and references using the model adapter 

method deleteNode(Object source) and deleteEdge(EdgeType edgeType, Object source, Object 

target) respectively, and then updates all its data structures that had a reference to the deleted 

objects and references. However, the interpreter does not check the consistency of the models, 

after having revoked a TGG rule. Very often the model is getting inconsistent afterwards, and 

other TGG rules would need to be revoked as well. However, this feature is not yet supported, 

but the interpreter could also maintain a tree like hierarchy of applied TGG rules. Therefore, 

the interpreter could trace back affected objects and revoke its TGG rules as well. 

The delete edge event is handled exactly in the same way than the delete node event. 

Restriction 

The interpreter algorithm is not restricted to context free graph grammars, where every lefthand 

side consists of a single node but rather supports also context- sensitive graph grammars 

in which both left- and right-hand side of a production are graphs. The only restriction is that 

all nodes of the graph grammar needs to be reachable from at least one node on the left-hand 

side. 

27

Chapter 3 

Case Study 

This case study is meant to improve the current interpreter architecture and to help understanding 

which requirements and features are needed to perform a wide range of different 

model transformations. Therefore, an example transformation from the Fujaba TGG model 

to the ComponentTools TGG model has been developed. During the implementation the 

interpreter architecture was evaluated and the results were then used to enhance the architecture 

in order to get the transformation done. These enhancements will be described in chapter 4. 

Additionally, this example transformation will help to ease the modelling of a ComponentTools 

TGG model, because from this work on the Fujaba editor can be used to create any TGG model 

that ought to be the input for the interpreter and then ues the interpreter itself to transform 

this model into the corresponding ComponentTools format. This avoids the painful usage of 

the very user unfriendly ComponentTools editor, which was generated automatically by the 

Eclipse Modeling Framework (EMF) (see Section 3.2). 

The special on this transformation is that both models are triple graph grammar models, 

whereas the ComponentTools TGG model also serves as the underlying graph model for the 

interpreter. The implementation of the example transformation was done in a kind of bootstrapping 

manner. Therefore, the first TGG rules and graph type models were modeled with 

the ComponentTools TGG- editor, which could be then used to transform a small part of the 

Fujaba model into the ComponentTools model. The results were then again used as TGG ruleand 

graph type model- input for the interpreter, in order transform an even bigger part of the 

Fujaba model. This step was repeated until the whole Fujaba model could be sucessfully transformed. 

Figure 3.1 shows the bootstrapping process during the implementation of the example 

transformation. 

28

3.1. FUJABA- TGG EDITOR 

EMF Editor 

Fujaba Editor 

Modeling 

ComponentTools TGGModel 

FujabaTGG2ComponentToolsTGG' 

Fujaba TGGModel 

FujabaTGG2ComponentToolsTGG 

Rule- Catalog & Type Models 

Modeling Input 

Result 

TGG Interpreter 

Figure 3.1 : Bootstrapping the ComponentTools TGG model. 

new input 

ComponentTools TGGModel 

FujabaTGG2ComponentToolsTGG'' 

In the following sections both TGG models and its elements will be introduced. Besides, the 

two model editors are explained and how both models were mapped onto each other. 

3.1 Fujaba- TGG Editor 

The Fujaba Tool Suite [9] is an UML [10] development environment that features among other 

things, the modelling of software systems and the code generation out of it. It was developed 

at the University of Paderborn and it supports the most common UML diagrams like class- and 

activity diagrams and statecharts. 

Additionally, Fujaba provides a plugin mechanism that was used to extend the Fujaba- model 

and the editor to support the modeling of TGG rules. Figure 3.2 shows the extended part of the 

Fujaba model. 

29


UMLIncrement 

UMLDiagramitem 

UMLConnection 

UMLLink 

+ modifier: Integer 


+ type: Integer 

ASGElement 


UMLObject 




ASGDiagram 

UMLDiagram 

UMLObjectDiagram 

TGGDiagram 0..* 

diagram2element 

0..* 


0..* 

TGGObject 

+ side: Integer 

outlink2source 

0..1 

inlink2target 0..* 

0..* 

0..1 0..* 

TGGLink 

Figure 3.2 : The extended part of the Fujaba model 

3.1.1 Creating a Fujaba TGG Model 

A Fujaba TGG model can be created by specifying three different class diagrams that represent 

the meta type definition of the source-, correspondence- and target- models. Each element in a 

class diagram represents a certain type for one of the elements found in the three in- memory 

model instances. 

The TGG model also contains TGG rules (TGG diagrams) that describe the single transformation 

steps. A TGG diagram is an object diagram using the types defined in the class diagrams. 

These object structures define the three graph rewriting rules and every element in the TGG 

diagram references one type of the above defined graph type models. 

3.1.2 TGG Rule Specification in Fujaba 

A TGG model can easily be created by using the Fujaba editor to model the class diagrams and 

the TGG rules. The figure 3.3 shows the Fujaba editor and a TGG diagram that describes the 

transformation step of a Fujaba TGG diagram object into the corresponding ComponentTools 

Graph object. 

30


Figure 3.3 : The Fujaba editor showing a TGG diagram. 

TGG objects can be edited in a dialog (see figure 3.4 ) that allows to set important properties 

listed below. 

• The objects name. 

• The type of the object, which references one of the class diagram’s elements. 

• The side, which sets one of the three graph rewriting rules (source, correspondence or 

target). 

• The modifier ’left’ or ’right’, which defines the actual rule side of the element (in Fujaba 

they are called ’None’ and ’Create’) 

• The constraint that defines whether the node should be treated as normal, or as condition 

node. 

31

3.2. ECLIPSE/EMF TGG EDITOR 

3.1.3 Fujaba Graph Type Model 

Figure 3.4 : The part of the Fujaba graph type model. 

The Fujaba model provides the very basic UML elements like classes, associations and others, 

in order to model UML diagrams. Since the current interpreter architecture does not support 

abstraction (see Chapter 5) the graph type in figure 3.5 was modeled without it. 

UMLProject 

0..1 

project2diagram 

0..* 

UMLClassDiagram 


0..* 


UMLClass 


0..1 

class2attr 

0..* 

UMLAttr 



0..* 

0..1 

0..1 

0..1 

0..1 

0..* 

0..1 


project2typelist 

0..* 

typelist2type 

role2targetclass 

0..* 

assoc2rightrole 

0..1 

0..1 

0..1 

UMLRole 

+ adornment: Integer 

UMLTypeList 

0..1 

0..* 

UMLAssoc 


attrexpr2attr 

TGGDiagram 



0..* 

0..1 

assoc2leftrole 

0..1 

0..* 

0..* 


0..* 

TGGObject 



+ side: Integer 


0..1 

object2class 

object2attrexpr 

UMLAtrrExprPair 

+ expression: Integer 

+ operator: Integer 


outlink2source 

inlink2target 

0..1 0..* 

link2assoc 

Figure 3.5 : The Fujaba graph type model as a UML class diagram. 

3.2 Eclipse/EMF TGG Editor 

0..1 

0..1 

0..* 

0..1 

0..* 

1 

0..* 

TGGLink 

0..* 


expr2assignedexpr 

The ComponentTools infrastructure was developed by a project group at the University of 

Paderborn. The tool allows to easily apply formal methods in the development cycle of 

a system. Therefore, an application interface was developed as well as a transformation 

32 

0..1 

0..*


mechanism to allow third party tools to be integrated, by transforming formal models into 

each other and then allow different tools to work on one and the same model. Therefore, 

ComponentTools has developed a triple graph grammar model that is used to model the rules 

and the type definitions (see Chapter 2.4 ) that are necessary for the transformation. 

The ComponentTools TGG model, generated by the Eclipse Modeling Framework (EMF) [11]. 

EMF is a modeling framework and code generation facility for building tools and other applications. 

From a model specification described in XMI, EMF provides tools and runtime support 

to produce a set of Java classes implementing the model, a set of adapter classes that enable 

viewing and command-based editing of the model, and a basic editor. 

3.2.1 Creating a ComponentTools TGG Model 

A ComponentTools TGG model consists of three graph types, which define the meta type 

definition of the three in- memory models, in the same way the class diagrams do in a Fujaba 

TGG model. A graph type model consists of node-, edge- and propertytypes, whereas each 

of these elements represent a type for one of the elements in the in- memory model instances. 

Furthermore, the TGG model contains TGG rule graphs and each rule again defines the three 

graph rewriting rules for the triple graph grammar application. A TGG rule graph consists 

of nodes, edges and properties and resembles object diagrams, in the same way as the TGG 

diagrams do in Fujaba. 

3.2.2 TGG Rule Specification in ComponentTools 

A ComponentTools TGG model can be created by using the tree based XMI editor, which was 

generated by the EMF framework. Figure 3.6 shows the ComponentTools editor modeling a 

TGG rule that transforms a TGG diagram into the corresponding ComponentTools graph. 

33


Figure 3.6 : The ComponentTools Editor modeling a TGG rule graph. 

The elements can be edited by using the property cell editor, which can be seen in the lower 

part of figure 3.6 . 

3.2.3 ComponentTools Meta Model 

A graph type may contain element types like node- and edgetypes, whereas the first one 

can have multiple property types that represents certain class attributes. A TGG rule graph 

contains elements like nodes and edges. Nodes can have properties that again have a reference 

to an element type. Figure 3.7 shows the underlying graph model of the interpreter architecture 

as an EMF class diagram. 

34

3.3. MAPPING BOTH MODELS 

Figure 3.7 : The ComponentTools graph type model as EMF class diagram. 

3.3 Mapping both models 

As seen above, the Fujaba- and the ComponentTools- models are very similar to each other. 

They almost have the same structure and they provide the same information that is necessary 

for a transformation with triple graph grammars. Therefore, the Fujaba model could have been 

easily used as underlying graph model for the interpreter too. 

However, modelling a new graph model with EMF was the first choice, because Fujaba 

contains some elements and features that are useless for the interpreter architecture and hence 

would have made it unnecessarily complex. EMF also provides comfortable ways to map 

other models to its internal Ecore model representation, which is used for the model code- and 

editor generation. Nevertheless, Fujaba would have been a good choice as well, since some of 

the enhancement being made to the interpreter are actually adapted from the Fujaba model. 

The following two sections show an example TGG rule in both, the Fujaba as well as the 

CoamponentTools notation. Both diagrams are modeled as UML object diagram whereas the 

related elements are drawn in the same color. Both models only show the part of the model 

that is necessary for defining the TGG rule that transforms a Fujaba TGG diagram into the 

corresponding ComponentTools graph. 

35


3.3.1 Representation in ComponentTools 

The TGGCatalog of the ComponentTools model represents the root element of the project. 

This object references the GraphTypes and the TGG rule Graphs. The GraphTypes, source 

(blue color), correspondence (orange color) and target (green color), define the element types 

of the three in- memory models. The Graphs and its elements define the object structure of the 

three graph rewriting rules (source, correspondence and target). Each of these object structures 

and its elements reference elements of one of the GraphTypes. 

nt1:NodeType 

name:=”UMLProject” 

n1:Node 

name:=”project” 

left:=true 

source:=true 

et1:EdgeType 

role:=”project2diagram” 

et2:EdgeType 

role:=”diagram2project” 

e1:Edge 

left:=false 

map:=true 

gt1:GraphType 

description:=”source” 

e2:Edge 

left:=false 

map:=true 

nt2:NodeType 

name:=”TGGDiagram” 

pt1:PropertyType 

name:=”name” 

type:=”String” 

n2:Node 

name:=”tggdiagram” 

left:=false 

source:=true 

t1:TGGCatalog 

p1:Property 

operator:=ASSIGN 

et3:EdgeType 

gt2:GraphType 

description:=”correspondence” 

corres1:NodeType 

name:=”project2catalog” 

role:=”p2t2p” et4:EdgeType 

et6:EdgeType 

role:=”t2g2t” 

e3:Edge 

left:=true 

map:=true 

3.3.2 Representation in Fujaba 

corres2:NodeType 

name:=”tggdiag2graph” 

cor1:Node 


left:=true 

map:=true 

g1:Graph 

role:=”p2t2t” 

descr:=”TGGDiagram2Graph” 

et7:EdgeType 

role:=”t2g2g” 

gl1:GraphElementTypes 

e4:Edge 

left:=true 

map:=true 

cor2:Node 

e7:Edge e8:Edge 

left:=false 


left:=false 

left:=false 

map:=true 

map:=true 

map:=true 

nt3:NodeType 

name:=”TGGCatalog” 

et5:EdgeType 

role:=”tggcatalog2graph” 

n3:Node 

name:=”tggcatalog” 

side:=”right” 

modifier:=”none” 

Figure 3.8 : ComponentTools TGG model at runtime. 

et5:EdgeType 

role:=”tggcatalog2graph” 

gt3:GraphType 

description:=”target” 

nt4:NodeType 

name:=”Graph” 

e5:Edge 

left:=false 

target:=true 

e6:Edge 

left:=false 

target:=true 




n4:Node 

name:=”graph” 


modifier:=”create” 

p1:Property 

operator:=ASSIGN 

The Fujaba notation is very similar (see Figure 3.9 ). The root element is an object of type 

UMLProject, which references the UMLClassDiagram objects source (blue color), correspondence 

(orange color) and target (green color). These again define the element types of the 

three in- memory models. The UMLProject object also has a reference to the TGGDiagram 

object (purple object td1). The TGG diagram and its references define the object structure 

of the three graph rewriting rules (source, correspondence and target). Each of these object 

structures and its elements reference elements of one of the class diagram. 

36


c1:UMLClass 

name:=”UMLProject” 

adornment:=0 

cd1:UMLClassDiagram 

name:=”source” 

a1:UMLAssoc 

name:=”project2diagram” 

r1:UMLRole r2:UMLRole 

o1:TGGObject 

name:=”project” 

side:=”left” 


adornment:=0 

t1:TGGLink 


t2:TGGLink 

c2:UMLClass 

name:=”TGGDiagram” 

a1:UMLAttr 



o2:TGGObject 

name:=”tggdiagram” 

side:=”left” 


p1:UMLProject 

t6:TGGLink 


td1:TGGDiagram 

r5:UMLRole 

adornment:=0 

r6:UMLRole 

adornment:=3 

name:=”TGGDiagram2Graph” 

r9:UMLRole 

adornment:=0 

r10:UMLRole 

adornment:=3 


name:=”correspondence” 

c5:UMLClass 


a3:UMLAssoc 

name:=”p2t2p” 

a3:UMLAssoc 

name:=”t2g2t” 

cor1:TGGObject 


side:=”map” 


c6:UMLClass 


a4:UMLAssoc 

name:=”p2t2t” 

a5:UMLAssoc 

name:=”t2g2g” 

tl1:UMLTypeList 

r7:UMLRole 

adornment:=0 

r8:UMLRole 

adornment:=3 

r11:UMLRole 

adornment:=0 

r12:UMLRole 

adornment:=3 

t5:TGGLink 


c3:UMLClass 

name:=”TGGCatalog” 

a2:UMLAssoc 


name:=”target” 

name:=”tggcatalog2graph” 

adornment:=0 

c4:UMLClass 

name:=”Graph” 

r3:UMLRole r4:UMLRole 

o3:TGGObject 

name:=”tggcatalog” 



adornment:=0 

t3:TGGLink 


t4:TGGLink 

a2:UMLAttr 



o4:TGGObject 

name:=”graph” 




t2:UMLAttrExprPair 

t7:TGGLink 


cor2:TGGObject 


t8:TGGLink 



expression:=”name:=o4.getName()” 

side:=”map” 


t2:UMLAttrExprPair 

expression:=”name:=o2.getName()” 

3.3.3 Mapping The Elements 

Figure 3.9 : Fujaba TGG model at runtime. 

In this section, the elements of both models are mapped onto each other. Therefore, in the 

following sections, the TGG rules are introduced that are needed for the transformation. For 

a better understanding of a correct model transformation, the creation of bidirectional references 

have been explicitly modeled by using two references in both direction. However, both 

the Fujaba and the ComponentTools model allow to maintain the consistency of bidirectional 

references within the model, and therefore, would not make it necessary to explicitly set both 

directions. 

3.3.3.1 UMLProject2TGGCatalog 

The UMLProject- and TGGCatalog- objects represent the root elements of their models and 

therefore must be transformed manually by hand . That means, whenever a Fujaba model 

is to be transformed into a ComponentTools model, its UMLProject object is transformed by 

creating a new TGGCatalog object by hand. This is also called the axiom, since there exists no 

precondition for this rule. 

3.3.3.2 UMLClassDiagram2GraphType 

The UMLClassDiagram- and the GraphType- objects represent the root object for the element 

types. The first one references UMLClass-, UMLAssoc- (associations) and UMLAttr- 

37


(attributes) objects, whereas the latter one references Node-, Edge- and Property type objects. 

This rule creates a new GraphType object as well as references in both directions to the TG- 

GCatalog object for every UMLClassDiagram object referenced by an UMLProject object. 

Vice versa, it creates a new UMLClassDiagram object and references in both directions to the 

UMLProject object for every GraphType object referenced by a TGGCatalog object (see Figure 

3.10 ). 

p1:UMProject 


++ 

++ 


(a) 

diagram2project 

++ 

t1:TGGCatalog 

catalog2graphtype graphtype2catalog 

++ ++ 

++ 

gt1:GraphType 

Figure 3.10 : Transforms an UMLClassDiagram object into a GraphType object. 

3.3.3.3 TGGDiagram2Graph 

The TGGDiagram- and the Graph- object represents the root element for the TGG rule 

object structures. The first one references TGGObject- (objects), TGGLink- (references) and 

UMLAttrPairExpr- (attribute instances) objects, whereas the latter one references Nodes, 

Edges and Properties. 

This rule creates a new Graph object as well as new references in both directions to the TG- 

GCatalog object for every TGGDiagram object referenced by the UMLProject object. Vice 

versa, it creates a new TGGDiagram object and references in both directions to the UMLProject 

object for every Graph object referenced by the TGGCatalog object (see Figure 3.11 ). 

p1:UMProject 

++ diagram2project 

++ 



(a) 

(b) 

t1:TGGCatalog 

catalog2graph 

graph2catalog ++ 

++ 

++ ++ 

g1:Graph 

Figure 3.11 : Transforms an TGGDiagram object into a Graph object. 

3.3.3.4 UMLTypeList2GraphElementTypes 

The UMLTypeList- and the GraphElementTypes- object represents a type list. The first one 

contains UMLClass objects only, whereas the latter one contains all Node- and Edge- Type 

objects. The GraphElementTypes element was introduced to allow Node- and Edge- Types to 

be referenced by multiple GraphTypes (see Chapter 4). 

38 

(b)


This rule creates a new GraphElementTypes object as well as a new reference for the TGGCatalog 

object for the one UMLTypeList object that is referenced by the UMLProject object. Vice 

versa, it creates a new UMLTypeList object and a new reference for the UMLProject object for 

the one GraphElementTypes object that is referenced by the TGGCatalog object (see Figure 

3.12 ). 

p1:UMProject 

typelist2project 

++ 

project2typelist 

++ 

++ 

list:UMLTypeList 

(a) 

t1:TGGCatalog 

catalog2elementtypelist 

++ 

++ 

elementtypelist2catalog 

glist:GraphElementTypes 

Figure 3.12 : Transforms an UMLTypeList object into a GraphElementTypes object. 

3.3.3.5 UMLClass2NodeType 

The UMLClass- and the NodeType- object represent an element type. The first one may be 

referenced as type by the TGGObject objects and can be connected to other UMLClass objects 

using UMLAssoc objects. The latter one is referenced as type by a Node object and can be 

connected to other NodeType objects using EdgeType objects. 

This rule creates a new NodeType object as well as new references in both directions to the 

GraphElementTypes object for every UMLClass referenced by the UMLTypeList object. Vice 

versa, it creates a new UMLClass object and references in both directions to the UMLTypeList 

object for every NodeType object referenced by the GraphElementTypes object (see Figure 

3.13 ). 

list:UMLTypeList 

c1:UMLClass 

(a) 

(b) 

glist:GraphElementTypes 

++ 

type2typelist typelist2type elementtypelist2elementtype 

elementtype2elementtypelist ++ 

++ ++ 

n1:NodeType 

Figure 3.13 : Transforms an UMLClass object into a NodeType object. 

3.3.3.6 UMLClass2NodeType-Correspondence 

This rule creates new references in both directions between a GraphType object and a Node- 

Type object for every reference found between an UMLClassDiagram object and an UMLClass 

object. Vice versa, it creates new references in both directions between an UMLClassDiagram 

object and an UMLClass object for every reference found between a GraphType object and a 

NodeType object (see Figure 3.14 ). 

39 

(b)


cd:UMLClassDiagram 

element2diagram diagram2element 

c1:UMLClass 

3.3.3.7 UMLAssoc2EdgeType 

++ ++ 

(a) 

gt:GraphType 

++ graphtype2elementtype 

elementtype2graphtype ++ 

n1:NodeType 

Figure 3.14 : This rule only transforms a reference. 

An UMLAssoc (association) object in Fujaba represents the connection type between two 

UMLClass objects (see Figure 3.15 ). Therefore, it references a left and a right UMLRole 

object, which again references the source and the target class objects. Additionally, the role 

has a field called ’adornment’, which defines the association kind between the two classes. The 

adornment can be set to the following values: 

• NONE - The roles target class gets a reference of the partner class. 

• REFERENCE - The roles target class won’t get a reference of the partner class. 

• AGGREGATION, COMPOSIION, QUALIFIED - All three are not supported by the 

ComponentTools model. 

When both, the left and right UMLRole ist set to NONE, the association is bidirectional. When 

one of the roles is set to REFERENCE, the association is unidirectional. 

UMLClass 


0..1 


assoc2rightrole 

0..* 

0..1 

UMLRole 

+ adornment: Integer 

UMLAssoc 

0..1 + name: String 

assoc2leftrole 

Figure 3.15 : The UMLAssoc part of the Fujaba model. 

The difficulty in transforming UMLAssocs is that there are many different kinds and each of 

it needs to be transformed differently. In ComponentTools, a connection type is defined as 

directed EdgeType between two NodeTypes. 

In the following, the TGG rules will be explained that are needed to get the transformation of 

the different UMLAssocs done. 

UMLAssoc2EdgeType-Bidirectional 

This rule creates two different EdgeType objects and new references in both directions to 

the GraphElementTypes object for every bidirectional UMLAssoc object referenced by an 

UMLClassDiagram object. Vice versa, it creates a new bidirectional UMLAssoc object (and a 

new left and right UMLRole object which are both set to NONE) and new references in both 

40 

0..1 

0..1 

(b)


directions to the UMLClassDiagram object for every pair of EdgeType objects cross referencing 

the same source and target NodeType objects and referenced by the GraphElementTypes 

object (see Figure 3.16 ). 

++ 

++ 

targetclass2role 

left:UMLRole 

adornment:=”NONE” 

right:UMLRole 



++ ++ 


++ 


rightassoc2rightrole 

++ 

rightrole2rightassoc 

++ 

++ 

c2:UMLClass 

c1:UMLClass 

++ 

leftrole2leftassoc 

++ 

leftassoc2leftrole 

(a) 

a1:UMLAssoc 

++ 


++ 

++ 

element2diagram 


n1:NodeType n2:NodeType 

++ 

outedge2source 

inedge2target ++ 

++ 

++ 

source2outedge 

++ 

++ 

++ 

inedge2target 

e1:EdgeType 

e2:EdgeType 

++ 

elementTypes2type 

++ 


graphtype2elementtype 

++ 

list:GraphElementTypes 

g1:GraphType 

(b) 

++ 

source2outedge ++ 


++ 


Figure 3.16 : Transforms a bidirectional UMLAssoc object into two EdgeType objects. 

UMLAssoc2EdgeType-Unidirectional-1 

This rule does the same as the rule UMLAssoc2EdgeType-Bidirectional, except that it only creates 

one new EdgeType object and new references in both directions to the GraphElementTypes 

object for every unidirectional UMLAssoc (left UMLRole is set to NONE, right UMLRole is 

set to REFERENCE) object referenced by an UMLClassDiagram object and vice versa creates 

an unidirectional UMLAssoc object for every EdgeType object that is referenced by the 

GraphElementTypes object and that has no corresponding EdgeType object showing in the 

other direction. 

++ 

++ 


left:UMLRole 


right:UMLRole 

adornment:=”REF” 

++ 



++ ++ 

++ 


++ targetclass2role 

role2targetclass ++ 

c2:UMLClass 

c1:UMLClass 


++ 

(a) 

++ 


++ 

a1:UMLAssoc 

diagram2element element2diagram 

++ ++ 


nt1:NodeType nt2:NodeType 

outedge2source inedge2target 

source2outedge target2inedge 

++ 

++ 

++ 

++ 

++ 

et1:EdgeType 

++ 


++ 

type2elementTypes 


gt1:GraphType 

(b) 

++ 


Figure 3.17 : Transforms an unidirectional UMLAssoc object into one EdgeType object. 

41


UMLAssoc2EdgeType-Unidirectional-2 

This rule does the same as the rule UMLAssoc2EdgeType-Unidirectional-1, except that it 

creates a new EdgeType object that references the source and the target NodeType object in 

the opposite direction. 

++ 

++ 


left:UMLRole 

adornment:=”REF” 

++ 



++ ++ 

++ 


right:UMLRole 


++ targetclass2role 

role2targetclass ++ 

c2:UMLClass 

c1:UMLClass 


++ 

(a) 

++ 


++ 

a1:UMLAssoc 

diagram2element element2diagram 

++ ++ 


nt1:NodeType nt2:NodeType 

inedge2target outedge2source 

target2inedge ++ 

++ source2outedge 

++ 

++ 

++ 

et1:EdgeType 

++ 


++ 

type2elementTypes 


gt1:GraphType 

(b) 

++ 



UMLAssoc2EdgeType-Bidirectional-SelfAssociation 

This rule does the same as the rule UMLAssoc2EdgeType-Bidirectional, except that the left 

and the right UMLRole object of the UMLAssoc object references the same target UMLClass 

object (see Figure 3.19 ). 

++ 

++ 

target2role 

++ 

role2target 

c1:UMLClass 

left:UMLRole right:UMLRole 

adornment:=”NONE” adornment:=”NONE” 


++ 

++ 

a1:UMLAssoc 

++ 


c1:UMLClassDiagram 

(a) 

role2target 


++ 

++ 

target2role 

++ 

leftassoc2leftrole rightassoc2rightrole 

++ 

++ 

++ 

++ 


++ 


++ 

++ 


n1:NodeType 

++ 

++ 

++ 

source2outedge target2inedge inedge2target 

++ 

++ 

++ outedge2source 

inedge2target target2inedge 

++ 

e1:EdgeType e2:EdgeType 

++ 


++ 



g1:GraphType 

(b) 

++ 


++ 


Figure 3.19 : Transforms a bidirectional self UMLAssoc object into two EdgeType objects. 

UMLAssoc2EdgeType-Reference 

42


This rule only creates new references between a GraphType object and an EdgeType object for 

every reference found between an UMLClassDiagram object and an UMLAssoc object. Vice 

versa, it creates new references in both directions between an UMLClassDiagram object and 

an UMLAssoc object for every reference found between a GraphType object and a EdgeType 

object. 

UMLAssoc2EdgeType-Unidirectional-1-SelfAssociation 

This rule does the same as the rule UMLAssoc2EdgeType-Unidirectional-1, except that it handles 

the self association (see Figure 3.20 ). 

++ 


++ 


++ ++ 

c1:UMLClass 

left:UMLRole right:UMLRole 

adornment:=”NONE” adornment:=”REF” 

++ 


++ 


a1:UMLAssoc 


(a) 

++ 


++ 


++ 


leftassoc2leftrole ++ 

++ 


++ 


nt1:NodeType 

++ ++ 

source2outedge 

target2inedge 

outedge2source inedge2target 

++ ++ 

++ 

et1:EdgeType 

++ 


++ 

type2elementtypes 


gt1:GraphType 

(b) 

++ 



3.3.3.8 UMLAttr2PropertyType 

The UMLAttr- and the PropertyType- object represents a property definition. The first one is 

referenced by UMLClass objects and the latter one by NodeType objects. 

This rule creates a new PropertyType object and a new reference in both directions to the 

NodeType object for every UMLAttr (attribute) object that is referenced by an UMLClass 

object. Vice versa, it creates a new UMLAttr object and a new reference in both direction to 

the UMLClass object for every PropertyType object that is referenced by a NodeType object 

(see figure 3.21 ). 

++ 

c1:UMLClass 

nt1:NodeType 

class2attr 

++ 

propertyType2nodeType 

++ 

attr2class 

++ 

nodeType2propertyType 

++ 

a1:UMLAttr 

(a) 


Figure 3.21 : Transforms an UMLAttr object into a PropertyType object. 

43 

(b) 

++


3.3.3.9 UMLAttrExprPair2Property 

The UMLAttrExprPair- and the Property- object represents an instance of a property. The 

first one is referenced by UMLObject objects and itself has a reference to an UMLAttr object, 

which defines its type. The latter one is referenced by Node objects an itself has a reference to 

a PropertyType object, which defines its type. 

This rule creates a new Property object and references in both directions to the Node object as 

well as a reference to the PropertyType object for every UMLAttrExprPair object referenced 

by an UMLObject object. Vice versa, it creates a new UMLAttrExprPair object and references 

in both direction to the Node object as well as a reference to the UMLAttr object for every 

Property object referenced by a Node object (see Figure 3.21 ). 

a1:UMLAttr 

attr2attrexpr 

++ 

o1:UMLObject 

p1:UMLAttrExprPair 

n1:Node 


node2property 

++ 

++ ++ 

attrexpr2object 

++ 

attrexpr2attr 

property2node 

++ ++ 

pt1:Property 

(a) (b) 


++ 

property2propertytype 

Figure 3.22 : Transforms an UMLAttrExprPair object into a Property object. 

3.3.3.10 UMLAttrExprPairAssigned2PropertyAssigned 

The class UMLAttrExprPair object in Fujaba represents an instance of the UMLAttr class. It 

defines a field of type String called expression that either stores a simle value or a complex 

object returned back by a method call. Additionally, it defines a field called operator to define 

how the expression is going to be evaluated. 

In the ComponentTools model a Property object represents an instance of the PropertyType 

class. The Property object can be assigned a simple value or another Property instance. 

The rule creates a reference from the Property object to the assigned Property object for every 

UMLAttrExprPair object that references another UMLAttrExprPair object through its expression 

field. Vice versa, it sets the expression property of the two UMLAttrExprPair objects for 

every Property object referencing another Property object (see Figure 3.23 ). 

o1:UMLObject 


expression:=”o2.getText()” 

operator:=”:=” 


only existing in the GraphType model 

o2:UMLObject 



expression:=”o1.getName()” 

operator:=”:=” 

n1:Node 

node2property 

p1:Property 

(a) (b) 

++ 

n2:Node 

node2property 

property2assignedProperty 

p2:Property 

Figure 3.23 : Transforms the expression field into an assigned property. 

44


3.3.3.11 TGGObject2Node 

The TGGObject- and Node- objects represent an element instance in both models and are both 

contained in a TGG rule object diagram. The first one is referenced by a TGGDiagram object 

and can be connected to other TGGObject- objects using UMLLink objects. Additionally, 

it references a UMLClass object, which defines its type. The latter one is referenced by a 

Graph object and can be connected to other Node objects using Edge objects. Additionally, it 

references a NodeType object, which defines its type. 

This rule creates a new Node object and references in both directions to the Graph object for 

every TGGObject object referenced by a TGGDiagram object. Vice versa, it creates a new 

TGGObject and references in both directions to the TGGDiagram object for every Node object 

referenced by a Graph object (see Figure 3.24 ). 

c1:UMLClass 

++ 

class2object 

object2class 

++ 



++ 

++ 


o1:TGGObject 

(a) 

++ 

g1:Graph 

graph2node 

++ ++ 

node2graph 

++ 

n1:Node 

(b) 

nt1:NodeType 

node2nodetype 

++ 

nodetype2node 

++ 

Figure 3.24 : Transforms an UMLObject object into a Node object. 

3.3.3.12 TGGLink2Edge 

The TGGLink- and Edge object represent a connection instance in both models. The first is 

referenced by a TGGDiagram object and connects two TGGObject objects with each other. 

Additionally, it references an UMLAssoc object which defines its type. The latter one is 

referenced by a Graph object and connects two Node objects with each other. Additionally, it 

references an Edge object, which defines its type. The following rules transform the different 

TGGLink objects into an Edge objects. 

TGGLink2Edge-Forth 

This rule creates a new Edge object and references in both directions to the source Node object, 

to the target Node object and to the Graph object, respectively and a reference to the 

EdgeType object for every TGGLink object that has a reference to an UMLAssoc object and 

that is referenced by a TGGDiagram an (see Figure 3.25 ). 

45


source:UMLClass 

role2target 

left:UMLRole 



a1:UMLAssoc 

TGGLink2Edge-Back 

object2class 


source:TGGObject 

assoc2link ++ 

++ 

link2assoc 

l1:TGGLink 

target:TGGObject 

(a) 


++ 

link2source source2link 

++ ++ ++ 

link2target target2link 

++ 

++ 

++ 


source:Node 

edge2source 

source2edge 

++ ++ 

++ 

e1:Edge 

node2type 

target:Node 

edge2type 

source:NodeType 

graph2element 

edge2target 

++ ++ 

++ 

element2graph 

target2edge ++ 

++ 

(b) 


e2:EdgeType 

g1:Graph 

Figure 3.25 : Transforms an UMLLink object into an Edge object. 

This rule does the same as the TGGLink2Edge-Forth, except that it creates an Edge that is 

directed in the other direction (see Figure 3.26 ). 

target:UMLClass 

role2target 

right:UMLRole 



a1:UMLAssoc 

object2class 

source:TGGObject 

assoc2link ++ 

++ 

link2assoc 


l1:TGGLink 


++ 

link2source source2link 

++ ++ ++ 

link2target target2link 

++ 

++ 

target:TGGObject 

(a) 

++ 


source:Node 

edge2source 

source2edge 

++ ++ 

++ 

e1:Edge 

node2type 

target:Node 

edge2type 

target:NodeType 

graph2element 

edge2target 

++ ++ 

++ 

element2graph 

target2edge ++ 

++ 

(b) 


e2:EdgeType 

g1:Graph 

Figure 3.26 : Transforms an UMLLink object into an Edge object (other direction). 

46

Chapter 4 

Realization 

This chapter discusses the problems that occurred during the implementation of the example 

transformation and it explains the enhancements beeing made to the interpreter and the underlying 

graph model in order to get the transformation to work. 

4.1 Common Problems 

Creating the TGG rules is the most difficult part, since the developer need to know both models 

in detail. However, once the rules are created the model transformation is just a push on the 

button. 

During the evaluation of the interpreter and the example implementation many errors have been 

corrected and improvements were made. The localization of errors was very difficult because 

the algorithm trace had to be analyzed in order to understand why the error occurred and where 

to find it. Therefore, in most cases the complete matching process had to be debugged. Due 

to the many recursions this very difficult. Below are the most common reasons for errors that 

caused the interpreter to produce strange results. 

• The modeled TGG rules and graph type definitions contained errors. (e.g. a modeling 

error, like a forgotten property setting). 

• The interpreter algorithm contained errors. (e.g. data structures were not maintained 

correctly). 

• The adapter implementation contained errors. (e.g. the implementation did not match 

the rule and the graph type definition) 

4.2 Problems and Solutions 

4.2.1 TGG Rules only creating References/Edges. 

During the transformation the problem occurred that UMLDiagramItems (UML- 

Classes,UMLAssocs...) can be contained by multiple ASGDiagrams (UMLClassDiagram, 

TGGDiagram...). Therefore, an UMLClass object can be referenced by multiple UMLClass- 

Diagram objects, but only at least one reference was transformed correctly. This was because 

other diagrams that had a reference on this element were thrown out of the front too early. 

Therefore, the front was extended and an EdgeMapping was introduced in order to track all 

the produced references so far. 

47

4.2. PROBLEMS AND SOLUTIONS 

4.2.1.1 EdgeMapping 

By transforming two models into each other, the source model needs to be parsed in order to 

reconstruct its structure and stepwise build up the target model. Therefore, the source graph 

rewriting rule of the TGG rules must be virtually reapplied on the source model. 

When a TGG rule could be applied successfully, elements matched with rule nodes only on 

the right side will be marked as produced. Additionaly, they will be marked as front elements, 

when they still have not yet produced neighbors. This border defines the TGG rules left and 

right side. 

In the first prototype version of the TGG interpreter elements have been thrown out of the 

front whenever all of its neighbors were reproduced. But to fully transform a model, it is also 

important to check whether all its references and hence all outgoing edges of a node can be 

reproduced. 

In the new version, an object is thrown out of the front only if all of its references and hence its 

outgoing edges have been successfully reproduced. 

An edge mapping will be created, when its reference was mapped with an edge of a TGG 

rule only on the right side. It contains the source- and target objects which are mapped with 

the source- and target nodes of the edge. Additionally, the edge type is stored to identify the 

mapped reference. 

public class EdgeMapping 

{ 

private Object sourceObject; 

private Object targetObject; 

private EdgeType edgeType; 

} 

public EdgeMapping(Object sourceObject,EdgeType edgeType,Object targetObject) 

{ 

this.sourceObject=sourceObject; 

this.edgeType=edgeType; 

this.targetObject=targetObject; 

} 

Figure 4.1 : The class EdgeMapping of the interpreter. 

The above enhancement allows to have rules that only creates references (see. 4.2 ). 

source 


:UMLClassDiagram :Corresp 


++ ++ 


assoc:UMLAssoc 

:Corresp 

target 

:GraphType 

++ 

graphtype2edgetype 

back:EdgeType 

Figure 4.2 : A rule that only creates a reference. 

48


4.2.2 TGG Rules only creating or changing Properties. 

4.2.2.1 PropertyMapping 

The above modification can be extended, such that a model is fully transformed only, whenever 

all its objects, references and properties are transformed. That allows to have TGG rules, only 

change or create properties of a an object. Although, this was possible before by using the 

structure of the TGG rules and define an own NodeType for this property, i.e. HeightNodeType, 

it is much easier and efficient by extending the front, such that objects are thrown out of it only 

if all its properties have been reproduced. However, this again has the disadvantage that the 

front might be getting polluted of objects, which properties can not be changed. Although, the 

transformation would be correct nevertheless, at the end of the transformation, the front would 

not be empty. Therefore the feature is currently not enabled. 

public class PropertyMapping 

{ 

private Object sourceObject; 

private PropertyType propertyType; 

} 

public PropertyMapping(Object sourceObject,PropertyType propertyType) 

{ 

this.sourceObject=sourceObject; 

this.propertyType=propertyType; 

} 

Figure 4.3 : PropertyMapping to trace the already produced properties. 

4.2.3 TGG rule condition. 

4.2.3.1 Property Operators 

In the ComponentTools model a Node object can reference multiple Properties. A Property 

has a certain value assigned, which can be evaluated through the interpreter at runtime by 

comparing its values with the properties defined by the in- memory model objects. 

The new version now supports multiple operators for the evaluation. Therefore, the Property 

element in the ComponentTools model had to be extended by an operator that has one of the 

following values: 

• Equal (==) 

• Greater Equal (>=) 

• Greater (>) 

• Less Equal (


The interpreter can now evaluate the rule node property value with the in- memory model object 

property value by using the rule nodes property operator. 

The following simplified rule transforms a bidirectional UML association into two EdgeTypes 

with different directions, depending on the adornment property of the UMLRole object. When 

both the left and right UMLRole object is set to ’NONE’ a bidirectional association has been 

found and two EdgeTypes will be created in the ComponentTools model. 

left:UMLRole 

adornment==0 

source:UMLClass 

target:UMLClass 

source 

:UMLClassDiagram 

assoc:UMLAssoc 

name:=forth.getName() 

right:UMLRole 

adornment==0 


:Corresp 

:Corresp 

:Corresp 

:Corresp 

target 

:GraphType 

back:EdgeType 

name:=assoc.getName() 

out2source 

source:NodeType 

:GraphElementTypes 

forth:EdgeType 

name:=assoc.getName() 

in2target 

in2target out2source 

target:NodeType 

Figure 4.4 : Transforms a bidirectional UMLAssoc into two EdgeTypes. 

4.2.3.2 Comparing Properties with each other. 

Mapping properties were used during the creation of the target model objects. Therefore, a 

correspondence node could define a mapping property that consisted of the source- and target 

node properties. Whenever the target object was created, its attributes were initialized with the 

values from the mapping properties source property. 

In the new version of the interpreter architecture, mapping properties were removed out of the 

graph model. Instead, properties can now be assigned and compared with arbitrary properties 

from other nodes, using the operators from section 4.2.3.1. That allows to compare the fields of 

arbitrary objects, from both, the source, and the target in- memory model. The only restriction 

is that node properties can only be compared with properties from other nodes when they are 

connected by an edge or by a correspondence node. That guarantees that the target node, when 

not already happend, can always be matched directly within the in- memory model objects to 

retrieve the actual property value. 

4.2.3.3 EMF Containment References 

In the old version of the ComponentTools model, GraphElementTypes like Node- and Edge- 

Types could only be contained by one GraphType. Although this is the usual case, sometimes 

it happens that different GraphTypes reference each other, or may be composed of several 

other GraphTypes. The problem occurred during the transformation of UMLClass objects, 

since they can be referenced by multiple UMLClassDiagrams objects and therefore caused the 

transformation to produce wrong results, because NodeTypes were only added to at most one 

GraphType. Though, the lost references were no problem during the transformation from left 

to right (Fujaba2ComponentTools), the model was not transformed correctly and therefore, 

50


could not be transformed back into the original Fujaba model. 

Therefore, a new element called GraphElementTypes was added to the ComponentTools model 

to store all the defined element types as containment reference and then allow other GraphTypes 

to just reference these. 

4.2.3.4 Online evaluation of cardinalities. 

In the new version of the interpreter cardinalities are evaluated at runtime to improve the efficiency. 

Therefore, whenever a NodeMapping and its outgoing Edges are explored (using the 

exploreEdges method), the edges are sorted depending on the size of the in- memory model 

neighbors that are returned by the RealModelAdapter’s method getNeighbors(EdgeType edgeType, 

Object source). 

4.2.3.5 Optional- /Negative edges 

Negative- and optional edges can be used to express that certain object references must not, or 

must not necessarily exist, in order to fully apply the TGG rule. For example, an Object a can 

only be transformed if it has no reference to a neighbor object of type B, or an Object a can 

always be transformed, regardless whether it has a reference to a neighbor object of type B 

or not. Therefore, the underlying graph model was changed, such that an Edge has a Property 

called KIND, which can be set to the following values. 

• NORMAL - The default setting to treat an Edge as normal. 

• OPTIONAL - The Edge must not necessarily be matched within the in- memory model 

instances. 

• NEGATIVE - The Edge must not be matchable within the in- memory model instances 

in order to apply the TGG rule. 

The interpreter handles negative edges in the way that it returns false in the current transformation 

step, whenever it can map a negative edge within the references of an in- memory model 

object. In the case of optional edges, it continuous with the transformation anyway, even when 

it can not match an optional Edge within the references of an in- memory model object, and 

there is no other reference left to try. 

Although, this feature is supported by the interpreter, it was not yet needed in any of the TGG 

rules and might get thrown out again, when it turns out to be a problem while trying to prove 

the correctness of a transformation (see Chapter 5). It was just added to try different modeling 

techniques. 

Sometimes negative edges can be avoided by splitting up a transformation step into two separate 

rules and then refining each rules using a more restrictive context around the transforming 

object. 

51

Chapter 5 

Conclusion 

The implemented example transformation and the enhancements being made during the 

work of this thesis helped to improve the current interpreter architecture and to get a better 

understanding about the assets and drawbacks of a model transformation with triple graph 

grammars. Additionally, the implemented example now helps to ease the modeling of the 

ComponentTools- TGG rule’s set and the GraphType definition models needed for a transformation, 

by using the Fujaba editor, instead of the very user unfriendly ComponentTools 

EMF editor. Therefore, a created Fujaba TGG model can be transformed into the necessary 

ComponentTools format. 

As a result it turned out that the underlying interpreter graph model is all important for being 

compatible to perform a wide range of different model transformation. The difficulty is that the 

interpreter has to be as general and efficient as possible but may not make any assumption about 

the models to be transformed, other than all must underly an object oriented meta model, in 

order to interpret them as a a graph. Therefore, the ComponentTools GraphModel must contain 

the most common concepts used in a variaty of object oriented meta models. The following list 

shows the ones known so far: 

• Object oriented 

• Type and instance level 

• Abstract data types (types, operations, variables, conditions) 

• Primitive types 

• Abstraction (not yet supported) 

Although it is nice to have a clean Graph Grammar model as underlying model for the 

interpreter, it is not necessarily needed, because the required information could be also 

provided by using the Adaptable pattern [12] to extend an existing model, i.e. to store the 

triple graph grammar informations. That makes it is very easy to replace the underlying 

ComponentTools model with any object oriented model, i.e. Java or EMF. Therefore, it would 

be possible for the future to make the interpreter even more independent from its own model to 

support the usage of different underlying models. However, that would make it also necessary 

to let it make use of some sort of strategy interface (strategy pattern [12]) to always support all 

features that are used in any underlying model. 

One strategy could be for example the already mentioned Abstraction concept used in many 

object oriented meta models that would allow to have only one TGG rule for very simmilar ob- 

52

ject structures, which could then make use of the super type hierarchies defined in a GraphType 

model definition. 

Another result is that although the interpreter works very efficient and reliable working with it 

is very difficult. This is because very often the complete algorithm trace needs to be debugged, 

in order to understand why certain results are produced. Therefore, it would be very helpfull 

for the future to have a visual debug interface that allows to follow the interpreter algorithms 

matching process in order to track the errors. 

One more problem is the uniqueness of TGG rules. Sometimes it happens that different rules 

can be applied at the same time to one and the same object structure. This is very often, when 

rules are a subset of other rules. In the example transformation, the rule UMLAssoc2EdgeType- 

Unidirectional-Ref1 is a subset of the rule UMLAssoc2EdgeType-Unidirectional-Bidirectional. 

The problem occurs, when the rule is applied from the target- to the source side, because then 

the interpreter can not decide, whether a single found EdgeType object has to be transformed 

into a bidirectional, or into an unidirection UMLAssoc object. Although sometimes, it is possible 

to avoid these conflicts, by splitting up the transformation step, in order to make the rules 

unique again, very often it is not. In this case the interpreter needs to have a priority in which 

order to apply the rules. For example, the problem with the UMLAssocs could be solved, 

by ordering the TGG rules (preprocessing), such that the bigger one (UMLAssoc2EdgeType- 

Unidirectional-Bidirectional) is always tried to be applied first. 

Another feature to be implemented in the future is the matching of multiple TGG rules at 

the same time. That would allow the interpreter to decompose the TGG rules into common 

subgraphs and then match them at once. Figure 5.1 shows an example where two graphs are 

matched at the same time. 

r 3 

r 2 

C 

E A 

v 1, r 1 

v 2, r 2 

v 3, r 3 

v 4 

v 5 

r 1 

w 4 

w 8 

w 9 

D 

B 

r 4 

r 5 

v 3 

v 2 

C 

E A 

v 1 

w 5 w6 

r 4 

r 5 

w 2 

w 3 

w 4 

w 7 

K 

L 

w 1 

v 4 

v 5 

w 7 

w 8 

w 5 

K 

B 

C A 

Figure 5.1 : Decomposing TGG rules and match them at the same time. 

53 

B 

w 9 

L 

E 

w 1 

w 2 

w 4 

D 

w 3 

C w6

List of Figures 

2.1 A simple triple graph grammar rule. . . . . . . . . . . . . . . . . . . . . . . . 7 

2.2 Left side pre condition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 

2.3 Target right side, that needs to be created. . . . . . . . . . . . . . . . . . . . . 8 

2.4 The interpreter architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 

2.5 A graph type and its node-, edge- and propertytypes. . . . . . . . . . . . . . . 9 

2.6 An UML class diagram and its corresponding graph type model instance. . . . 9 

2.7 The model adapter interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 

2.8 Example, how the interpreter interacts with the model adapter. . . . . . . . . . 11 

2.9 Example implementation of the getNodeType routine. . . . . . . . . . . . . . . 11 

2.10 The graph- and graph type- meta model. . . . . . . . . . . . . . . . . . . . . . 12 

2.11 A graph and the referenced model type definition. . . . . . . . . . . . . . . . . 12 

2.12 A simple graph. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 

2.13 A directed graph. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 

2.14 An attributed graph. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 

2.15 A possible homomorphism f(A) = G,f(B) = H,f(C) = F . . . . . . . . . . 15 

2.16 Mapping functions between two graphs. . . . . . . . . . . . . . . . . . . . . . 16 

2.17 Searchtree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 

2.18 This routine checks if a graph is subgraph of another graph. . . . . . . . . . . . 19 

2.19 This routine is used to match two nodes with each other. . . . . . . . . . . . . 19 

2.20 This routine explores all outgoing edges of a node. . . . . . . . . . . . . . . . 20 

2.21 Nodes were already successfully reproduced . . . . . . . . . . . . . . . . . . . 21 

2.22 The graph rewriting rule that could be reaplied next. . . . . . . . . . . . . . . . 22 

2.23 The front that marks the border for the graph grammar rule’s left and right side. 22 

2.24 This routine parses a graph. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 

2.25 This routine updates the front. . . . . . . . . . . . . . . . . . . . . . . . . . . 23 

2.26 This routine matches two nodes. . . . . . . . . . . . . . . . . . . . . . . . . . 24 

2.27 The five steps of the interpreter algorithm. . . . . . . . . . . . . . . . . . . . . 25 

3.1 Bootstrapping the ComponentTools TGG model. . . . . . . . . . . . . . . . . 29 

3.2 The extended part of the Fujaba model . . . . . . . . . . . . . . . . . . . . . . 30 

3.3 The Fujaba editor showing a TGG diagram. . . . . . . . . . . . . . . . . . . . 31 

3.4 The part of the Fujaba graph type model. . . . . . . . . . . . . . . . . . . . . . 32 

3.5 The Fujaba graph type model as a UML class diagram. . . . . . . . . . . . . . 32 

3.6 The ComponentTools Editor modeling a TGG rule graph. . . . . . . . . . . . . 34 

3.7 The ComponentTools graph type model as EMF class diagram. . . . . . . . . . 35 

3.8 ComponentTools TGG model at runtime. . . . . . . . . . . . . . . . . . . . . 36 

3.9 Fujaba TGG model at runtime. . . . . . . . . . . . . . . . . . . . . . . . . . . 37 

3.10 Transforms an UMLClassDiagram object into a GraphType object. . . . . . . . 38 

3.11 Transforms an TGGDiagram object into a Graph object. . . . . . . . . . . . . 38 

54

3.12 Transforms an UMLTypeList object into a GraphElementTypes object. . . . . . 39 

3.13 Transforms an UMLClass object into a NodeType object. . . . . . . . . . . . . 39 

3.14 This rule only transforms a reference. . . . . . . . . . . . . . . . . . . . . . . 40 

3.15 The UMLAssoc part of the Fujaba model. . . . . . . . . . . . . . . . . . . . . 40 

3.16 Transforms a bidirectional UMLAssoc object into two EdgeType objects. . . . 41 

3.17 Transforms an unidirectional UMLAssoc object into one EdgeType object. . . . 41 


3.19 Transforms a bidirectional self UMLAssoc object into two EdgeType objects. . 42 


3.21 Transforms an UMLAttr object into a PropertyType object. . . . . . . . . . . . 43 

3.22 Transforms an UMLAttrExprPair object into a Property object. . . . . . . . . . 44 

3.23 Transforms the expression field into an assigned property. . . . . . . . . . . . . 44 

3.24 Transforms an UMLObject object into a Node object. . . . . . . . . . . . . . . 45 

3.25 Transforms an UMLLink object into an Edge object. . . . . . . . . . . . . . . 46 

3.26 Transforms an UMLLink object into an Edge object (other direction). . . . . . 46 

4.1 The class EdgeMapping of the interpreter. . . . . . . . . . . . . . . . . . . . . 48 

4.2 A rule that only creates a reference. . . . . . . . . . . . . . . . . . . . . . . . 48 

4.3 PropertyMapping to trace the already produced properties. . . . . . . . . . . . 49 

4.4 Transforms a bidirectional UMLAssoc into two EdgeTypes. . . . . . . . . . . 50 

5.1 Decomposing TGG rules and match them at the same time. . . . . . . . . . . . 53 

55

Bibliography 

[1] Online source. 2006. Information about MDA. URL: http://www.omg.org/mda. 

[2] Online source. 2006. OMG homepage. URL: http://www.omg.org. 

[3] A. Gepting, J. Greenyer, Ekkart Kindler, A. Maas, S. Munkelt, C. Pales, T. Pivl, O. Rohe, 

Vladimir Rubin, M. Sanders, A. Scholand, C. Wagner, and Robert Wagner. Component 

Tools: A vision of a tool. In Proc. of the 11th Workshop on Algorithms and Tools for 

Petri Nets (AWPN2004), Paderborn, Germany, September 30 - October 1, pages 37–42, 

September 2004. 

[4] M. Weber and E. Kindler. The petri net kernel, 2002. 

[5] M. Jungel, E. Kindler, and M. Weber. The petri net markup language. 

[6] Ekkart Kindler, Vladimir Rubin, and Robert Wagner. An Adaptable TGG Interpreter for 

In-Memory Model Transformation. In Andy Schürr and Albert Zündorf, editors, Proc. 

of the 2nd International Fujaba Days 2004, Darmstadt, Germany, volume tr-ri-04-253 of 

Technical Report, pages 35–38. University of Paderborn, September 2004. 

[7] Douglas R. Hofstadter. Godel Escher Bach: An Eternal Golden Braid. Basic Books, Inc., 

1999. 

[8] Online source. 2004. Entry from Wikipedia URL: http://en.wikipedia.org/ 

wiki/NP-Complete. 

[9] Online source. 2006. Fujaba homepage. URL: http://www.fujaba.de. 

[10] Online source. 2006. UML homepage. URL: http://www.uml.org. 

[11] Online source. 2006. Information about EMF. URL: http://www.eclipse.org/ 

emf. 

[12] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design patterns: 

Abstraction and reuse of object-oriented design. Lecture Notes in Computer Science, 

707:406–431, 1993. 

56

Bachelor thesis by Oliver Rohe

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?