paper - Business Informatics Group

Transcription

TU Wien
Business Informatics Group
Institut für Softwaretechnik und Interaktive Systeme
Güzide Selin Altan
On the Usability of Triple Graph Grammars
for the Transformation of Business Process
Models - An Evaluation based on FUJABA
Magisterarbeit zur Erlangung des akademischen Grades
eines Magister der Sozial- und Wirtschaftswissenschaften
eingereicht bei o. Univ.-Prof. Mag. Dipl.-Ing. Dr. Gerti Kappel
mitbetreuende Assistentin Mag. Marion Murzek
Wien, January 15, 2008
1
Abstract
In recent years the need for business process model transformation has
increased. The primary reason for this is the importance of business to business
interoperability. A lot of research is done in this area. Several transformation
techniques exist in the field of MDA which is the model driven architecture as
defined by Object Management Group (OMG).
In Business Process Modeling many modeling languages such as Business
Process Modeling Notation, UML 2.1 Activity Diagrams, Event-Driven Process
Chains et cetera are used. There is also a certain diversity in transformation techniques such as ATL, QVT or Kermeta. Most model transformation approaches
focus on software development, and less in business processes. Therefore some
approaches may be more or less suitable for this task than others.
In this master thesis, a transformation approach, namely Triple Graph
Grammars will be inspected for its suitability in business process model transformation. Event-driven Process Chains and Activity Diagrams from UML 2.x
are chosen as business process modeling languages because of the wide spread
popularity of these languages. Fujaba will be used as transformation tool for its
Triple Graph Grammar support and its extendibility.
In the thesis the business process modeling languages Event-driven Process
Chains and Activity Diagrams are described. Furthermore, several example
models for Event-driven Process Chains and Activity Diagrams are defined. In
the practical part the goal is to develop Fujaba plug-ins for those modeling
languages, as well as to define the Triple Graph Grammars rules based on the
new plug-ins. The example models will be needed to test if the Triple Graph
Grammar rules are intend correctly.
Fujaba is an open source project from the University of Paderborn. Its primary
topic is to provide an extendable platform for UML, Story Driven Modeling and
Graph Transformation platform with the ability to add plug-ins. In the master
thesis this tool is used because of its mature Triple Graph Grammar support
Another reason is its extensibility which is useful for creating custom plug-ins
for Event-driven Process Chains and Activity Diagrams.
The plug-ins are developed with Java and rely on the meta models of Activity
Diagrams and Event-driven Process Chains. The prepared meta models are also
used when defining the Triple Graph Grammar rules as initial point. The meta
models and the transformation are focused on Control Flow of business processes,
because of its central importance in business process modeling. Organizational
flow is also included as a secondary view.
2
In order to make a statement on how suitable the described approach is,
a list of criteria is defined. Based on this criteria business process model
transformation with triple graph grammars will be evaluated.
3
Kurzfassung
In den letzten Jahren ist der Bedarf an Modelltransformation im Bereich von
Geschäftsprozessmodellierung angestiegen. Der Hauptgrund dafür ist die Bedeutung von Business-to-Business Interoperabilität. In diesem Bereich wird auch
sehr viel geforscht. Im Bereich von MDA, wie er von der Object Management
Group definiert wurde, existieren bereits einige Transformationstechniken.
In der Modellierung von Geschäftsprozessen werden viele Modellierungssprachen, wie etwa Business Process Modeling Notation, UML 2.1
Activity Diagram oder Event-driven Process Chains und so weiter verwendet.
Auch bei Transformationssprachen gibt es eine gewisse Vielfalt, wie zum Beispiel
ATL, QVT, oder Kermeta. Die meisten Modelltransformationsansätze legen den
Fokus auf Softwareentwicklung, und weniger auf Geschäftsprozesse. Aus diesem
Grund können sich verschiedene Ansätze mehr oder weniger für diese Aufgabe
eignen als andere.
In dieser Masterarbeit wird ein Transformationsansatz, nämlich Triple Graph
Grammars, auf seine Eignung für Modelltransformation von Geschäftsprozessen
hin untersucht. Ereignisgesteuerte Prozessketten und UML 2 Aktivitätsdiagrame
werden dafür als Geschäftsprozesssprache ausgewählt, da sie sehr verbreitet
sind. Fujaba wird als Transformationswerkzeug eingesetzt, da es Triple Graph
Grammars unterstützt und erweiterbar ist.
In dieser Arbeit werden die Geschäftsprozessmodellierungssprachen Ereignisgesteuerte Prozessketten und Aktivitätsdiagrame beschrieben. Weiters werden
mehrere Beispiele für diese Sprachen definiert. Im praktischen Teil ist das Ziel,
Fujaba-Plugins für die Modellierungssprachen und darauf basierend Triple Graph
Grammar Regeln zu erstellen. Die Beispielmodelle werden verwendet, um die
Korrektheit der Triple Graph Grammar Regeln zu testen.
Fujaba ist ein Open-Source Projekt von der Universität Paderborn. Sein
Hauptziel ist es, eine erweiterbare Plattform für UML, Story Driven Modeling
und Graphtransformation mit Erweiterbarkeit durch Plug-ins zur Verfügung
zu stellen. In dieser Arbeit wird dieses Tool aufgrund seiner fortgeschrittenen
Triple Graph Grammar Unterstützung verwendet. Ein weiterer Grund ist die
Erweiterbarkeit. Dadurch ist es möglich, eigene Plug-ins für Ereignisgesteuerte
Prozessketten und Aktivitätsdiagrame zu erstellen.
Die Plug-ins sind in Java entwickelt und basieren auf den Metamodellen der
Ereignisgesteuerte Prozessketten und Aktivitätsdiagrame. Diese Metamodelle
werden auch beim Definieren der Triple Graph Grammar Regeln verwendet. Die
Metamodelle und die Transformation konzentrieren sich auf den Kontrollfluss
von Geschäftsprozessen, weil diese Sicht von zentraler Wichtigkeit dafür ist. Die
Organisationssicht wird zusätzlich auch betrachtet.
4
Um eine Aussage zu treffen, wie geeignet der beschriebene Ansatz ist, wird ein
Kriterienkatalog definiert. Basierend auf diesen Kriterien wird die Transformation von Geschäftsprozessen mit Triple Graph Grammars evaluiert.
5
Özet
Son yıllarda yönetsel süreç modelleme dönüşümlerine olan gereksinim oldukça
artmıştır. Bunun temel nedeni işten-işe birlikte işlerliğindeki önemdir. Bu konu
ile ilgili çok fazla araştırma yapılmaktadır. OMG Grubu (Object Management
Group) tarafından tanımlanmış model sürücülü mimari olan MDA (Model
Driven Architecture) alanında pek çok transformasyon mevcuttur.
Yönetsel Süreç Modellemesinde, Business Process Modeling Notation, UML
2.1 Activity Diagrams, Event-driven Process Chains gibi birçok modelleme dili
kullanılmaktadır. ATL, QVT veya Kermeta gibi dönüşüdm tekniklerinde de
birtakım çeşitlemeler bulunmaktadır. Pek çok model dönüşüm yaklaşımlarında
yazılım geliştirmeye yönetsel süreçlerden çok daha fazla odaklanılmaktadır. Bu
nedenle de yönetsel süreç modellemede bazı yaklaşımlar diğerlerine göre daha
fazla veya daha az uygun olabilir.
Bu yüksek lisans tezinde, yönetsel süreç modeli dönüşümüne uygunluğu
nedeni ile üçlü- çizge dilbilgisi (Triple Graph Grammars) olarak adlandırılan bir
dönüşüm yaklaşımı incelenmektedir. UML 2.x’in olaya- dayalı süreç zincirleri ve
activite diyagramları, bu dillerin yaygın biçimde kullanımları nedeni ile, yönetsel
süreç modelleme dili olarak seçilmiştir. Fujaba ise, üçlü - çizge dilbilgisini desteklemesi ve genişletilebilirliği nedeni ile, dönüşüm aracı olarak kullanılacaktır.
Bu çalışmada yönetsel süreç modelleme dilleri olaya- dayalı süreç zincirleri
ve aktivite diyagramları açıklanmıştır. Ayrıca olaya- dayalı süreç zincirleri
ve aktivite diyagramlarına da birkaç örnek verilmiştir. Uygulama bölümünün
amacı modelleme dilleri için uyumlu ekler geliştirmek ve ayrıca üçlü- çizge
dilbilgisi kurallarını bu yeni uyumlu eklere dayalı olarak tanımlamaktır. Üçlüçizge dilbilgisi kuralları doğru tasarlanmışsa örnek modellerin test edilmeleri
gerekecektir
Fujaba Paderborn Üniversite’sinde geliştirilmiş bir açık kaynak projesidir. Öncelikli konuları UML için, SDM (Story Driven Modeling) ve çizge
dönüşümü platformunun uyumlu ekler ile genişletilebilir birer platform olmalarını sağlamaktı.
Bu yüksek lisans tezinde, güçlü üçlü- çizge dilbilgisi desteği nedeni ile,
bu aygıt kullanılmıştır Bu aygıtı seçmenin bir başka neden ise, olaya dayalı
süreç zincirleri ve aktivite diyagramları için, özel uyumlu ekler yaratmak üzere
genişletilebilmesidir.
Uyumlu ekler Java dilinde yazılmıştır ve bunlar aktivite diyagramları ile olayadayalı süreç zincirlerinin meta modellerine dayanmaktadır. Hazırlanan meta
modeller ayrıca üçlü- çizge dilbilgisi kuralları tanımlanırken başlangıç noktası
olarak kullanılmıştır. Meta modeller ve dönüşüm, yönetsel süreç modellemesin-
6
deki önemleri nedeni ile, yönetsel süreçlerin kontrol akışına odaklanmıştır;
organizasyonel akış da ikinci bakış açısı olarak ilave edilmiştir.
Yukarıda açıklanan yaklaşımın ne kadar yerinde olduğunu betimlemek üzere bir
kriterler listesi tanımlanmıştır. Üçlü çizge dilbilgisi ile yönetsel süreç modelleme
bu kriterlere göre değerlendirilmektedir.
7
Eidesstattliche Erklärung
Ich erkläre an Eides statt, daß ich die vorliegende Arbeit selbständig und ohne
fremde Hilfe verfasst, andere als die angegebenen Quellen nicht benützt und die
den benutzten Quellen wörtlich oder inhaltlich entnommenen Stellen als solche
kenntlich gemacht habe.
Wien, 16.1.2007
Güzide Selin Altan
8
Acknowledgements
Grateful acknowledgement is made to the following:
Zeynep and Ender Altan, my parents, who constantly supported me until the
end and also sponsored my education which led to the completion of this thesis.
Philipp Huber who provided me utmost moral support when ultimately needed.
Robert Wagner who advised and helped me when I was experimenting with
transformations in Fujaba.
Last but not least, Marion Murzek and Gerti Kappel who supervised and
guided me along the preparation process of this thesis.
9
Contents
I. Introduction
12
1. Introduction
1.1. Motivation . . . . . . . . . . .
1.2. Model Driven Engineering . .
1.3. Business Process Modeling . .
1.4. Related Work . . . . . . . . .
1.5. Structure of the Master Thesis
13
13
13
15
16
17
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
II. Business Process Modeling Languages
18
2. Event-driven Process Chains
2.1. History of Event-driven Process Chains . . . . . . .
2.2. General Description of Event-driven Process Chains
2.3. Meta Model . . . . . . . . . . . . . . . . . . . . . .
2.3.1. Function . . . . . . . . . . . . . . . . . . . .
2.3.2. Event . . . . . . . . . . . . . . . . . . . . .
2.3.3. Logical Operator . . . . . . . . . . . . . . .
The Logical Operator “AND“ . . . . . . . .
The Logical Operator “OR“ . . . . . . . . .
The Logical Operator “XOR“ . . . . . . . .
2.3.4. Organizational Unit . . . . . . . . . . . . . .
2.3.5. Flow Connector . . . . . . . . . . . . . . . .
Control Flow Connector . . . . . . . . . . .
Organizational Flow Connector . . . . . . .
2.4. Example Models . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
19
19
19
20
22
22
23
23
24
25
26
27
27
27
27
3. UML Activity Diagrams
3.1. Object Management Group (OMG) . . . .
3.1.1. History of UML . . . . . . . . . . .
3.1.2. General Description of UML . . . .
3.2. General Description of Activity Diagrams .
3.3. Meta model . . . . . . . . . . . . . . . . .
3.3.1. Activity . . . . . . . . . . . . . . .
3.3.2. Activity Node . . . . . . . . . . . .
3.3.3. Action Node . . . . . . . . . . . . .
Action . . . . . . . . . . . . . . . .
CallBehavior Action . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
32
32
32
33
34
34
37
37
37
37
37
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Contents
3.4. Control Node . . . . . .
Initial Node . . .
Final Nodes . . .
Decision Node . .
Merge Node . . .
Fork Node . . . .
Join Node . . . .
3.4.1. Activity Edge . .
3.4.2. Activity Partition
3.5. Example Models . . . .
10
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
38
38
38
39
39
40
41
41
42
43
III. Transformation with Fujaba
47
4. Problem description
4.1. Conceptual Element-to-Element Mapping . . . . . . . . . . . . . .
4.2. Mapping Variants . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
48
49
5. Triple Graph Grammars
5.1. Pair Graph Grammars versus Triple Graph Grammars . . . . . .
5.2. Triple Graph Grammars Rules . . . . . . . . . . . . . . . . . . . .
5.3. TGG Rule Algorithm . . . . . . . . . . . . . . . . . . . . . . . . .
59
59
60
62
6. Developing Fujaba Plug-ins
6.1. Fujaba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2. Required Software for Triple Graph Grammars . . . . . . . . . . .
6.3. Steps to build the Event-driven Process Chain and Activity Diagram Plug-ins . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.1. Implementing the Plug-in Interface . . . . . . . . . . . . .
6.3.2. Defining the Meta Models . . . . . . . . . . . . . . . . . .
6.3.3. Connecting to Fujaba´s Meta Model . . . . . . . . . . . .
6.3.4. Implementing the Actions . . . . . . . . . . . . . . . . . .
6.3.5. Defining Concrete Syntax . . . . . . . . . . . . . . . . . .
6.3.6. User Interface . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.7. Implementing the Frame Decorator . . . . . . . . . . . . .
6.3.8. Defining the Plug-in Description . . . . . . . . . . . . . . .
6.3.9. Deploying the Plug-in . . . . . . . . . . . . . . . . . . . .
6.3.10. What Features Are Supported in Both Plug-ins? . . . . . .
6.4. Problems Faced When Using Fujaba . . . . . . . . . . . . . . . .
6.4.1. Example Models in Fujaba . . . . . . . . . . . . . . . . . .
64
64
66
7. Defining TGG Rules for Model Transformation
7.1. Model Transformation Project . . . . . . . . . . .
7.1.1. Correspondence Meta Model . . . . . . . .
7.1.2. MoTE Meta Model . . . . . . . . . . . . .
7.1.3. MoTE Rules . . . . . . . . . . . . . . . . .
7.1.4. Event-Driven Process Chain and Activity
Model . . . . . . . . . . . . . . . . . . . .
78
79
79
81
82
. . . . .
. . . . .
. . . . .
. . . . .
Diagram
. . . . .
. . . .
. . . .
. . . .
. . . .
Meta
. . . .
66
66
67
67
68
69
71
72
73
73
73
74
75
83
Contents
11
7.2. Defining Triple Graph Grammar Rules with Fujaba´s TGG
7.2.1. Mapping of Fork/Join and Decision/Merge Nodes .
7.3. Java Project with Triple Graph Grammar Rules . . . . . .
7.4. Lessons learned . . . . . . . . . . . . . . . . . . . . . . . .
8. Evaluation of Triple Graph Grammars with Fujaba
8.1. Criteria Catalog . . . . . . . . . . . . . . . . . .
8.1.1. Approach . . . . . . . . . . . . . . . . .
8.1.2. Rule Organization . . . . . . . . . . . .
8.1.3. Rule Application Control . . . . . . . . .
8.1.4. Application Conditions . . . . . . . . . .
8.1.5. Syntactic Separation . . . . . . . . . . .
8.1.6. Traceability Support . . . . . . . . . . .
8.1.7. Incrementality . . . . . . . . . . . . . . .
8.1.8. Directionality . . . . . . . . . . . . . . .
8.1.9. Consistency Checking . . . . . . . . . . .
8.1.10. Maintenance . . . . . . . . . . . . . . . .
8.1.11. Usability . . . . . . . . . . . . . . . . . .
8.2. Lessons learned . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Editor 85
. . . . 98
. . . . 98
. . . . 101
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
102
102
103
103
104
104
104
104
105
105
105
106
106
107
9. Conclusion
109
9.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
9.2. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
List of Abbreviations
111
List of Figures
112
List of Tables
115
List of Listings
116
Bibliography
117
12
Part I.
Introduction
13
1. Introduction
1.1. Motivation
The need for model transformation has increased recently. Model integration
when companies merge, model translation for business to business interoperability and model synchronization within a company are some of the reasons for
the need of business process model transformations (see Figure 1.1). In model
integration, models conforming to different business process modeling languages
are integrated to create a new model, which conforms to another business process
modeling language. In model translation, models conforming to one business
process modeling language are transformed to models conforming to another
language. In model synchronization pairs of models are synchronized after user
changes [MKM06].
Figure 1.1.: Different Model Transformation Scenarios, taken from [MKM06]
Most of the work done about model transformation is in the field of software
modeling. In comparison to that, little work has been done to integrate model
transformation into the business process modeling area. In this master thesis the
question is, if model transformation with Triple Graph Grammars may also be
applied in the area of business process modeling.
The aim of the work is to translate models of two different business process
modeling languages into each other with the transformation approach Triple
Graph Grammars using Fujaba and to make an evaluation about it.
1.2. Model Driven Engineering
Model Driven Engineering (MDE) is a model based software design approach. In
this, models are considered the central artefact of software development. Model
1. Introduction
14
Driven Architecture (MDA) is a well-known MDE initiative, developed by the
OMG [MDA07]. MDA aims to replace code as the central artefact generated by
a software engineering process with models.
Software development has risen in complexity ever since it exists. The
software crisis in the 1960s and 1970s is an early example, which illustrates this
issue [Dij72]. More processing power makes it possible to write more complex
programs. However, without appropriate development tools and programming
languages, it becomes hard to manage this complexity. During the software
crisis, this resulted in generally low-quality programs, which were created in
over-time and over-budget development projects.
With the rising complexity and size of the software developed, the programming languages used, also evolved [MSU04]. Assembler languages, as used in the
early days of software development, are machine-oriented and reside therefore
at a very low abstraction layer. Later, languages appeared, which provide a
somewhat higher abstraction layer. A notable example for these languages
is C, which is not as machine-bound as assembler languages. In the 1980s,
object-oriented languages gained acceptance. These languages reside at an even
higher abstraction level, and provide techniques for structuring complex code, so
that it can be maintained more easily by the developers.
In the 2000s, languages like Java, C#, or Ruby are very popular because of
their high abstraction. As next logical step, MDA proposes not to use a specific
programming language for implementing software [MSU04]. The software should
be modeled using a modeling language like UML. Later on, code for a specific
platform is generated from the software model. This is achieved using platformindependent models and transforming them into platform-specific models by
adding platform specific information.
Because code in a specific programming language may also be seen as a model
conforming to a meta model, code generation may also be viewed as model
transformation. For this reason, model transformation is a key technology in
model driven engineering and model driven architecture in particular. From a
more general point of view, model transformation is used to transform one or
more source models into one or more target models.
Nowadays, many model transformations approaches exist. In this thesis Triple
Graph Grammars are used, which are a graph based and declarative approach.
They have been introduced in the early nineties by Andy Schürr [Sch95]. Triple
Graph Grammar rules may be implemented using the tool Fujaba [Fuj07e]. It
is developed at the university of Paderborn and consists of several subprojects.
One of its projects support the use of Triple Graph Grammars. Moreover it has
an extendible architecture with ability the to add plug-ins.
1. Introduction
15
1.3. Business Process Modeling
There are several similar definitions of the term business process. According to
Davenport [Dav93] a business process is:
A structured, measured set of activities designed to produce a specific
output for a particular customer or market. It implies a strong emphasis on how work is done within an organization, in contrast to a
product focus‘s emphasis on what. A process is thus a specific ordering of work activities across time and space, with a beginning and an
end, and clearly defined inputs and outputs: a structure for action...
Taking a process approach implies adopting the customer‘s point of
view. Processes are the structure by which an organization does what
is necessary to produce value for its customers.
Several reasons exist for modeling business processes [Oul95]:
• Document the processes: Documenting the business processes is helpful to
deal with costumer requirements. Another reason to document the business
processes is for internal communication within a company.
• Analyze the processes: By analyzing the business processes their quality
may be improved. Potential problems or bottlenecks may be identified.
• Simulate the execution of the processes. In this case, process models are
executed using sample data, therefore it is possible to identify problems,
which cannot be found by statical analysis. This may be achieved using
workflow engines, or environments especially designed for business process
execution, for example, Business Process Execution Language [bpe07].
There are many business process modeling languages like UML Activity
Diagram, BPMN (Business Process Modeling Notation [bpm06]), Event- Driven
Process Chains [KNS92], IDEF (Icon Definition Language [ide93]) etc. For the
transformations in this master thesis UML 2.1 Activity Diagram and EventDriven Process Chains have been chosen because of their widespread usage and
acceptance.
Business process modeling languages contain different aspects, namely control
flow, organizational flow and informational aspects. This work concentrates
on the control flow and the organizational flow aspect. They are described in
detailed in the next sections.
In Figure 1.2, the focus of this thesis is illustrated. Model Transformation and
Business Process Modeling belong to the area Model Driven Engineering. This
thesis integrates and combines concepts of both subfields, and is therefore itself
a subfield of Model Driven Engineering.
1. Introduction
16
Figure 1.2.: Focus of this thesis
1.4. Related Work
This master thesis is set in the field of both business process modeling and model
transformation, see Figure 1.2. Especially model transformation is a current field
of research. There have also been other works, which deal with the integration of
business process languages and model transformation. For example, in [MK06]
Marion Murzek and Gerhard Kramler concentrated on different business process
languages and the problems concerning their transformation. They focused on
the control flow of the respective languages. Several issues are presented, which
frequently occur when transforming business process languages into each other.
Some of the issues found are also present in this thesis. Their respective solutions
are illustrated in ATL.
In [MKM06], Murzek et. al. present a pattern-based approach to the
transformation of business processes. Several patterns are presented, which
lie on a higher abstraction level than meta model elements generally used in
model transformation languages like ATL. As an example, the transformation of
ADONIS models into Event-driven Process Chains is shown. The latter is also
used in this thesis. The transformation scenarios in this thesis are similar to the
patterns as described by Murzek et. al.
Birgit Korherr and Beate List describe an UML profile for Event-driven
Process Chains in [KL06]. This profile may be used for modeling Event-driven
Process Chains using UML Activity Diagrams. Although no transformation
between the two languages is defined, a mapping of their concepts is introduced.
In [Stö06], Harald Störrle compares Event-driven Process Chains and UML
Activity Diagrams from a syntactic and semantic view. Also, the concerning
related application conditions are inspected. As a conclusion, the superseding of
1. Introduction
17
Event-driven Process Chains by UML 2.1 Activity Diagrams is predicted.
A comparison of four different graph-based transformation approaches is presented in [TEG+ 05] by Gabriele Taentzer et. al. The four languages compared
and evaluated are AGG, AToM3, VIATRA2 and VMTS. Triple Graph Grammars
with Fujaba are not included, the focus lies on other graph based transformation
languages.
In [RM06], Jan Recker and Jan Mendling describe the transformation between
BPMN to BPEL. Mismatches and problems of this transformation are discussed
and analyzed. They concentrate on a more theoretical point of view and do not
provide an implementation for the transformation.
1.5. Structure of the Master Thesis
Section 1 gives an introduction to MDE and business process modeling. Moreover, the motivation and aim of this master thesis is explained.
In Sections 2 and 3 the chosen business process modeling languages namely
Event-driven Process Chains and Activity Diagrams are introduced. Their meta
models and elements considering the syntax and notation are explained in detail.
Furthermore, example models are defined and modeled to illustrate how the
transformation will work.
In Section 4 the transformation scenarios are documented and modeled without
considering a specific model transformation approach. Thus, the problems are
identified and possible solutions are proposed.
In Section 5 a short introduction to Triple Graph Grammars is given. Its
features and functionality is explained.
In Section 6 the transformation tool Fujaba is introduced. It has been chosen
as transformation tool because of its Triple Graph Grammar support. As
preparatory work for model transformation, Event-driven Process Chain and
Activity Diagram plug-ins are written in Java and integrated to Fujaba´s library.
In Section 7 the Triple Graph Grammar rules for the transformation of
Event-driven Process Chains to Activity Diagrams with Fujaba are defined. The
problems and the solutions are illustrated.
Section 8 is about evaluating Triple Graph Grammars with Fujaba. Most
of the chosen criteria are based on the paper “Feature-based survey of model
transformation approaches“ by K. Czarnecki [CH06].
In the last section, a conclusion of this master thesis is provided.
18
Part II.
Business Process Modeling
Languages
19
In this section, the basic concepts of Event-driven Process Chains are explained.
Further, the history, general description and meta model is described and the
elements of Event-driven Process Chains are listed.
2.1. History of Event-driven Process Chains
The business process modeling language Event-driven Process Chains (EPC) has
been introduced in 1992 by Sheer, Keller and Nüttgens [KNS92].
Origins of the Event-driven Process Chains base on CIM (Computer Integrated
Manufacturing) which has been developed in 1980s by CASA/SME (Computer
and Automated Systems Association / Society for Manufacturing Engineers). In
CIM the whole manufacturing process is integrated. It contains both software
modeling and management concept, so it has a rather complex superstructure.
Furthermore, it has no special framework to realize modeling the business
processes within a company [Sch91].
In 2002, Prof. Markus Nüttgens and Prof. Frank Rump launched a community
named “Business Process Management with Event-Driven Process Chains“ at the
university of Hamburg. This community organizes workshops, does research and
publishes journals about business process management. Their major topics are
syntax, semantic, modeling concepts and application concepts of Event-driven
Process Chains. On the community‘s homepage numerous journals about its
topics can be found [EPC07].
2.2. General Description of Event-driven Process
Chains
Event-driven Process Chains are based on concepts of ARIS [Ari]. The architecture of ARIS consists of three aspects; data, function and organizational
(behavior) aspects. The data aspect contains environmental infrastructure and
data which is used by functions during the process. The function aspect describes
the control flow of the process. Organizational aspect consists of persons, roles
or departments which are involved during the process [Sch91]. Other tools
where Event-driven Process Chains are interpreted are SAP R/3 [SAP07], ARIS,
ADONIS [Boc05], and Visio [Vis].
20
This work concentrates on the function (behavior) aspect also known as
control flow aspect and organizational aspect of Event-driven Process Chains.
The control flow aspect is the main aspect of the business process modeling
languages. The organizational aspect has been chosen as the second aspect for
test and comparison purposes.
2.3. Meta Model
In this section the meta model of the Event-driven Process Chains (see Figure
2.1) will be described. It contains the control flow and the organizational aspects
of the Event-driven Process Chains.
The control flow aspect contains the elements Event, Function, Logical
Operators and Control Flow. The elements of the organizational view are the
Organizational Unit and Organizational Flow.
An Event-driven Process Chain consists of Process Objects, Organizational
Units and Flow Connectors. Process Objects and Organizational Units are nodes
in the Event-driven Process Chains. Process Objects may either be Functions,
Events or Logical Operators. Flow Connectors are edges of Event-driven Process
Chains. They are further subdivided into Control Flow and Organizational Flow.
Process objects and Organizational Units are connected via Flow Connectors.
An Event is also the first and the last element of an Event-driven Process
Chain, because there is no dedicated start or end element. It starts with one or
more Events and ends with one or more Events. An Event may have at most
two Control Flows: One incoming and one outgoing flow. The first Event in the
Event-driven Process Chains has no incoming Control Flow and the last Event
has no an outgoing flow. This is expressed in the meta model in Figure 2.1,
where Event to Control Flow is modeled as 0..1 to 1 relationship.
A Function in the Event-driven Process Chains has always one incoming and
one outgoing Control Flow. A Function may be a Basic Function or a Complex
Function. The Logical Operators may have multiple incoming and outgoing
Control Flows. There are three Logical Operators in the Event-driven Process
Chains, “AND“, “OR“, and “XOR“. Organizational Units are connected with
Functions via the Organizational Flow. An Organizational Unit has at least
one Organizational Flow. Events and Functions have to alternate, but it is not
possible to illustrate this constraint in the meta model.
Process Object, Flow Connector und EPCDiagram are abstract classes of the
Event-driven Process Chain meta model and are not used directly in diagrams,
however their subclasses are. In the following each element will be described
considering its syntax and notation.
Figure 2.1.: Event-driven Process Chain meta model
21
22
2.3.1. Function
The class Function in the meta model is an abstract class and may either be a
Basic Function or a Complex Function.
Basic Function
A Basic Function is a task which describes an Activity or a task that has to
be executed by a Organizational Unit in a certain period of time. They lead to
Events [Kor05]. Basic Functions are atomic, they cannot be further divided. A
Basic Function cannot call another Basic Function. Basic Functions and Events
have to alternate. The Basic Function is depicted by a rounded rectangle (see
Figure 2.2).
Figure 2.2.: Notation: Basic Function
Complex Function
The Complex Functions is used to model a sub-process call. A Complex Function has to be refined in another Event-driven Process Chain. The notation of
Complex Functions is a rectangle with rounded corners with a little Event-driven
Process Chain in it (see Figure 2.3).
Figure 2.3.: Notation: Complex Function
2.3.2. Event
An Event describes a business state. That is the situation after or before a
Function is executed. After an Event has occurred a Function can be executed.
23
Figure 2.4.: Notation: Event
Events trigger Functions. In an Event-driven Process Chain, it is not allowed
calling an Event immediately after another Event.
Event-driven Process Chains start and end with Events. They do not have a
special element like the Initial Node and Final Node of Activity Diagrams which
marks the beginning and end of the diagram. The notation of an Event is a
hexagon (see Figure 2.4).
2.3.3. Logical Operator
Logical Operators are used to connect Events and Functions by decisions or
parallel executions . There are three types of Logical Operators: “AND“, “OR“,
“XOR“.
Each of the three Logical Operators is used to split the flow into multiple
flows. When the execution of the subflows is finished, they have to be joined again.
The Logical Operator “AND“
“AND“ (depicted in Figure 2.5) is a logical operator that results in a value of
true by two or more operands if all operands are true. In Event-driven Process
Chains, “AND“ splits the execution path (Control Flow). After that two or
more paths are executed concurrently.
Figure 2.5.: Notation: The logical operator “AND“
The operands in Event-driven Process Chains are the paths that have to be
split and have to be joined after the execution (see Figure 2.6).
24
Figure 2.6.: The logical operator “AND“ splits
In addition, “AND“ is used to join two or more parallel paths (see Figure 2.7).
Figure 2.7.: The logical operator “AND“ joins
The Logical Operator “OR“
“OR“ is a logical operator that results in a value of true by two or more operands
if one or more of its operands are true. “OR“ is called “logical disjunction“ in
mathematics (inclusive alternative).
Figure 2.8.: Notation: The logical operator “OR“
“OR“ splits the Control Flow with a decision statement in two or more flows.
The activated flows are executed concurrently. As seen in Figure 2.9 only a
Function may trigger a logical disjunction.
25
Figure 2.9.: The logical operator “OR“ splits
After each subflow is executed they have to be joined with “OR“ again. Then
the flow proceeds with an Event or a Function. (see Figure 2.10)
Figure 2.10.: The logical operator “OR“ joins
The Logical Operator “XOR“
“XOR“ is a logical operator that results in a value of true by two or more
operands if exactly one of the operands has a value of true. “XOR“ is called
“exclusive disjunction“ in mathematics.
Figure 2.11.: Notation: The logical operator “XOR“
“XOR“ splits the control flow with a exclusive alternative statement in two or
more flows. Only one flow may be executed alternatively. Parallel execution of
paths is not allowed. As seen in the Figure 2.12 only a Function may trigger an
exclusive disjunction.
26
Figure 2.12.: The logical operator “XOR“ splits
After each single path is executed they have to be joined with “XOR“ again.
Then the flow proceeds with an Event or a Function. (see Figure 2.13)
Figure 2.13.: The logical operator “XOR“ joins
2.3.4. Organizational Unit
The Organizational aspect of Event-driven Process Chains is represented by
Organizational Units. Persons, departments and roles are illustrated with
Organizational Units. They are responsible for executing Functions. They are
connected with Functions via organizational flow connector.
Figure 2.14.: Notation: Organizational Unit
More than one Organizational Units may be involved in executing a Function.
The notation of an Organizational Unit is an ellipse with a vertical line inside
and is shown in Figure 2.14.
27
2.3.5. Flow Connector
Flow Connectors connect the Process Objects in Event-driven Process Chains.
There are two types of Connectors: Control Flow Connector and Organizational
Flow Connector.
Control Flow Connector
Functions, Events and Logical Operators are connected via Control Flow. The
notation of a Control Flow is an arrow and is depicted in Figure 2.15. Its arrow
head shows in which order the Events and Functions are executed.
Figure 2.15.: Notation: Control Flow Connector
Organizational Flow Connector
Organizational Units and Functions are connected with Organizational Flows. A
Function may be assigned to multiple Organizational Units with Organizational
Flows.
Figure 2.16.: Notation: Organizational Flow Connector
The notation of the Organizational Flow Connector is a simple line (see Figure
2.16). Because no execution order exists in the organizational view, no arrow is
used as organizational flow connector.
2.4. Example Models
As example scenario a home care providing company and three of its processes
are modeled. It is thought for old people who want to go on living at their home,
instead living in a residential home for the aged. They keep living independently
and the company supports their household and some medical treatments which
are prescribed from the doctor.
In the first model the process ”Patient orders Home Care” is described. As
soon as the order information is checked, the home care providing company
employee (HCPC Employee) makes an appointment for an interview with the
patient. It is also recommended that at least one relative of the patient attends
28
this interview as well.
During the interview, the care plan for the patient is discussed. If the patient
needs a medical plan, it will be planed by a doctor. The non-medical care
contains jobs to be done in the household, like cooking, washing. This does not
have to be done by nurses or licensed medical personnel. The medical care can
only be provided by nurses, doctors, or other licensed medical personnel. All of
the care takers (HCPC Care Taker) are personnel from the home care providing
company.
Afterwards, the patient is assigned to a hospital to appoint his or her care
need grade. According to this grade the costs for home care are compensated by
the state or the patient has to pay him or herself. If the care need grade is high
the home care providing company has to contact the state because the costs will
be compensated by the state.
If the patient has to pay for home care costs, a cost plan will be discussed with
the HCPC Employee. Finally, the medical plan and the payment methods both
from the company and the patient side are confirmed. So the process ”Home
Care Order” is finished. (see Figure 2.17)
The second process is the ”Home Care” process as seen in Figure 2.18. During
the days when home care is planned, personnel from care taker department
prepare the service car and equipment needed. After that, they are ready to
drive to their patients.
When a care taker (HCPC Care Taker) arrives at the patient´s home, and
nobody opens the door, he or she has to contact and inform the patient´s
relatives. When the patient is at home, the home activities will be done and
documented. The documented home care activities have to be sent to the
company after each home care via PDA.
The third process (Figure 2.19) shows the home care activities in detail. When
a care taker arrives at the patient, he or she goes through the patients home care
plan. Depending on the care plan, medical care, non-medical care or both of it
are done.
Activities like washing the patient, changing his clothes, washing dishes,
washing clothes, ironing, cooking, cleaning, tidying up do not belong to medical
care. Measuring the pulse, giving pills, injections, serums are tasks of the medical
care.
When the home care activities are done, the treatments are documented,
and sent to the company. Now the care taker is ready to drive to the next patient.
Figure 2.17.: Example Model 1: Home Care Order
29
Figure 2.18.: Example Model 2: Home Care
30
Figure 2.19.: Example Model 3: Home Care Activities
31
32
This section gives a short overview of Object Management Group, UML in general, and UML Activity Diagrams.
3.1. Object Management Group (OMG)
The OMG is an international non-profit computer industry consortium founded
in 1989. OMG sets enterprise integration standards for many technologies. UML
is its most used standard. It has hundreds of members, among them universities
or big and small software companies such as IBM, Oracle, Microsoft, Sun
Microsystems, Hewlett-Packard, Software AG, DaimlerChrysler, Intel, Siemens
etc.
The OMG covers a wide range of topics in the field of integration standards.
Real-time, Embedded and Specialized Systems, Analysis & Design, ArchitectureDriven Modernization, Business Modeling and Integration, Finance, Government,
Healthcare, Legal Compliance, Life Sciences Research count to its topics [Obj07].
Every company or university may join OMG as a member. The Members have
many advantages, they can join technical meetings, conferences and other events
of the OMG. They may vote and help developing the standards and specifications.
Further specifications of the OMG are Model Driven Architecture (MDA),
Common Warehouse Metamodel (CVM), Meta-Object Facility (MOF), Common
Object Request Broker Architecture (CORBA), XML Metadata Interchange
(XMI) and Business Process Modeling Notation (BPMN)and Systems Modeling
Language (SYsML).
3.1.1. History of UML
The roots of object-oriented modeling languages reach to the 70s and 80s of the
previous century. There have been a few developers experimenting in the area of
object-oriented analysis and design. The “Entity Relationship Model“ (ERM)
and the “Specification and Description Language“ (SDL) influenced first object
oriented modeling languages [Kor05].
In 1994 there were about 50 different object oriented modeling languages. At
that time, the most popular methods were the “Object Modeling Technique“
(OMT) developed by Rumbaugh, “Methods of Booch“ introduced by Booch and
“Fusion“ introduced by Coleman. Then, this techniques have began to merge
33
and new techniques were generated. “Object Oriented Software Engineering“
(OOSE) introduced by Jacobson, “OMT-2“ and a new development of the
“Methods of Booch“ have been most successfully [Kor05].
In 1995, Grady Booch from Rational Software Company and Jim Rumbaugh
from General Electric Research and Development Center began to work together.
Rumbaugh joined the Rational Software Company. They merged the Methods
of Booch and OMT and released their concept named “Unified Method“ in
October 1995. After Jacobson has been joined Booch and Rumbaugh, “OOSE“
integrated to Unified Method, as well. The new method was called “Rational
Unified Method“. In June 1996 UML 0.9 was published by these three developers. They got positive feedback and had motivation to go on working. In 1996,
the OMG requested for a proposal of a modeling standard. Booch, Rumbaugh
and Jacobson reacted and proposed UML 1.0. UML has been adopted to OMG
as modeling standard since November 1997 [Kor05].
Until that time, UML had only three developers: Booch, Rumbaugh and
Jacobson. After UML has been accepted by OMG, the number of its developers
grew, so that UML 1.1 could be released soon (1997) [OMG07b].
Since then several UML revisions have been released. Each of them had more
Functionality and refinements. New diagrams and features have been added,
and problems and lacks have been addressed and corrected. The current official
version is UML 2.1.1 which has been released in early 2007.
3.1.2. General Description of UML
UML is a language with a very broad scope that covers a large and diverse set of
application domains. [OMG07a, page 1]
UML may be used in various kinds of projects and in different ways. UML
is used to design software, to model business processes, to show parts of a
system or its activities, to show communication between systems, to explain the
functionality of a system etc.
UML currently consists of thirteen diagrams. These are divided into “Structure
Diagrams“ and “Behavior Diagrams“. Structure diagrams show the internal
structure of a system independent of time. Class Diagrams, Component
Diagrams, Composite Structure Diagrams, Deployment Diagrams, Package
Diagrams and Object Diagrams belong to structure diagrams of UML. Behavior
diagrams concentrate on the dynamic constructs in a system. They have
dynamic character and show the changes in diagrams depending on time. There
are eight behavior diagrams in UML: Activity Diagrams, Use Case Diagrams,
State Machine Diagrams, Interaction Diagrams, Sequence Diagrams, Interaction
Overview Diagrams, Communication Diagrams and Timing Diagrams.
34
The UML diagrams can be interchanged between tools with the “XML Meta
Interchange“ (XMI) standard which makes using UML much more attractive.
UML has a mechanisms called “UML Profiles“ which allows the user to extend
the language. It has also an addition called “Object Constraint Language“
(OCL). Using OCL the user can define logical expressions to create constrains
on diagrams.
There are many tools with UML support. The well-known UML tools are:
ARTISAN Studio from ARTISAN Software Tools [Art07], Enterprise Architect
from Sparx Systems [Ent07], Telelogic TAU from Telelogic AB [Tel06], Altova
UModel from Altova Inc [Alt07], MagicDraw from No Magic [Mag07], Visual
Paradigm from Visual Paradigm International Ltd. [Vis07] and IBM Rational
Software Architect (RSA) from IBM [IBM07].
3.2. General Description of Activity Diagrams
The Activity Diagram (AD) is used for modeling the behavior of a system.
Therefore, the Activity Diagram may be applied for software modeling as well
as for business process modeling.
The Activity Diagram shows the behavior of a system (human and machine).
The basic elements of a flow called “Actions“ are ordered in which sequence
they are executed or appeared, so Activity Diagrams depend on time. The
responsibilities for an Action may also be modeled in the Activity Diagram by
means of the element “Activity Partition“.
3.3. Meta model
The container element in the Activity Diagrams is the Activity. It contains the
abstract classes Activity Edge, Activity Node and Activity Partition.
Each Activity may have multiple Activity Edges and Activity Nodes. The
Activity Nodes are connected via Activity Edges. Each Activity Node may
have one or more incoming and outgoing Activity Edges. This is explained in
meta model in Figure 3.1, Activity Edge to Activity Node is modeled as * to 1
relationship.
An Activity may have multiple Activity Partitions. In this case, Activity
Nodes and Edges are contained in the Activity Partition.
There are two types of Activity Nodes: The Action Node and the Control
Node. The Action and Callbehavior Action are the different variants of the
35
Action Node. A CallBehaviour Action is a subactivity of an Activity.
The six Control Nodes modeled in the meta model in Figure 3.1 are:
• Initial Node
• Fork Node
• Decision Node
• Join Node
• Merge Node
• Final Node
Flow Final Node and Activity Final Node are specifications of the Final Node.
Figure 3.1.: Activity Diagram meta model
36
37
3.3.1. Activity
The Activity is the root element in an Activity Diagram. It contains the whole
process consisting of Activity Nodes and Edges. An Activity begins with one or
multiple Initial Nodes and ends, with one or more Final Nodes.
3.3.2. Activity Node
An Activity Node is an abstract class for points in the flow of an Activity
connected by edges. [OMG07b, page 335]
It is a general class for nodes which are connected by Activity Edges. It covers
the Action Nodes and the Control Nodes.
3.3.3. Action Node
The Action Node is the central element in an Activity Diagram. It may be
called and executed. An Action Node may have several incoming and outgoing
Activity Edges which establish the control flow between the nodes. The Action
and CallBehavior Action are specifications of the Action Node.
Action
The Action is a well-defined, basic step within an Activity and performs data
manipulation and processing. In the context of its parent Activity, it may not be
further decomposed. However, this does not mean that the Action is atomic. In
another context, it could be described more precise. The notation for an Action
is a rounded rectangle (see Figure 3.2).
Figure 3.2.: Notation: Action Node
CallBehavior Action
CallBehavior Action is a call Action that invokes a behavior directly rather
than invoking a behavioral feature that, in turn results in the invocation of that
behavior. [OMG07b, page 248]
38
Figure 3.3.: Notation: CallBehavior Action
A CallBehavior Action contains other Actions. These Actions are called if the
CallBehavior Action is executed. Its notation is shown in Figure 3.3.
3.4. Control Node
Control Nodes act as traffic switches managing tokens as they make their way
between Actions. [OMG07b, page 321]
Control Nodes organize the behavior of the flows in Activity Diagrams. There
are six variants of Control Nodes which are explained below.
Initial Node
An Initial Node is a Control Node which denotes the start of an Activity. An
Activity can have more than one Initial Node. As Initial Nodes are the first
elements in an Activity. They may not have incoming control flows. The
notation for Initial Nodes are filled circles, see Figure 3.4.
Figure 3.4.: Notation: Initial Node
Final Nodes
A Final Node is a Control Node which terminates the flow in an Activity, so it
is the last element in a flow. Because of this character it has only incoming but
no outgoing edges.
There may be multiple Final Nodes in an Activity Diagram. For example after
a flow splits into multiple flows the Activity may end in two or more different
variants. There are to types of Final Nodes: Flow Final Node and Activity Final
Node.
Flow Final Node
39
A Flow Final Node terminates a flow and not the whole Activity. An Activity
may have multiple Flow Final Nodes. It destroys all the tokens in its flow, all
the other flows in the Activity remain unchanged and continue. The notation of
a Flow Final Node is a circle with an ”X” embedded, see Figure 3.5.
Figure 3.5.: Notation: Flow Final Node
Activity Final Node
An Activity Final Node terminates all flows in an Activity. An Activity
may have multiple Activity Final Nodes. As soon as one Activity Final Node
is reached, the remaining tokens are killed immediately and the execution
terminates. The notation for an Activity Final Node is a circle containing a filled
circle, see Figure 3.6.
Figure 3.6.: Notation: Activity Final Node
Decision Node
A Decision Node is a Control Node which divides a flow in subflows. The guard
expressions of the outgoing Activity Edges is determine which flow should be
passed through. A Decision Node has one incoming and multiple outgoing edges.
When a token arrives at a Decision Node, the boolean expression is evaluated.
Based on the result the flow continues on exactly one outgoing edge. A parallel
execution of multiple edges is not allowed. A Decision Node is shown as an
empty rhombus. (see Figure 3.8)
Figure 3.7.: Notation: Decision Node
Merge Node
A Merge Node is a Control Node which merges the flows splitted by a Decision
Node into a single flow. So it has the opposite character of a Decision Node.
40
It has multiple incoming edges but only one outgoing edge. A Merge Node is
notated like the Decision Node with an empty rhombus, see Figure 3.8.
Figure 3.8.: Notation: Merge Node
Figure 3.9.: Example for using Decision and Merge Node
In Figure 3.9 a fragment from a possible Activity Diagram is given. The
Decision Node has one incoming edge and multiple outgoing edges. Merge node
has multiple incoming edges and one outgoing.
Fork Node
A Fork Node is a control node which splits a flow into synchronous subflows.
Unlike the Decision Node, no decision has to be made. The subflows go on
concurrently. A Fork Node has one incoming and multiple outgoing edges. The
notation for a Fork Node is a vertical line, see Figure 3.10.
Figure 3.10.: Notation: Fork Node
41
Figure 3.11.: Example for “Guard Expressions“ in correlation with Control Nodes
In Figure 3.11 two example models are shown. In the top model, a Decision
Node splits the diagram into two subflows. Depending on the “Guard Expressions“ ([guard: x], [guard: y]) on the outgoing edges, it is determined which
subflow has to be traversed. In the second model(see Figure 3.11, bottom), a
Fork Node splits the diagram into two synchronous subflows. If there is a parallel
split, no guard conditions are needed.
Join Node
A Join Node is a control node which acts as the opposite of a Fork Node. It joins
the synchronized flows to a single flow. Unlike the Fork Node, the Join Node
has multiple incoming edges and one outgoing edge. A Join Node is shown with
a vertical line, like a Fork Node, see Figure 3.12.
Figure 3.12.: Notation: Join Node
3.4.1. Activity Edge
An Activity Edge connects two Activity Nodes in an Activity. Activity
Edges are directed connections. Therefore their source and target element is an
42
Activity Node. Because edges are directed the order of the flow is also established.
Figure 3.13.: Notation: Activity Edge
An Activity Edge may have a “Guard Expression“ constraint. It is a control
mechanism for the transition of the Actions. If the Guard Expression is true, the
transition of the flow is allowed. Otherwise, (if it is false) the transition is not
allowed [OMG07b]. The notation for an Activity Edge is a line with an arrow
pointing to the next Action. (see Figure 3.13)
3.4.2. Activity Partition
An Activity Partition contains a set of Activity Edges and Activity Nodes which
have characteristics in common. It shows the responsibilities for these objects.
Furthermore it divides an Activity into partitions.
Figure 3.14.: Notation: Activity Partition
To show the organizational aspect of the business model, Activity Partitions
are used. All of the Actions have owners or responsibilities, they are marked with
Activity Partitions in Activity Diagrams.
An Activity Partition is shown with two, parallel lines and a name labeling
the partition in a box at one end (see Figure 3.14). The parallel lines are called
swimlanes. They may be oriented horizontal or vertical. Activity Edges and
nodes are positioned in the swimlanes.
Parallel and horizontal partition lines may be used together. Such an Activity
Partition is called multiple partition. This is the case if an Activity has more
than one owners or responsibilities.
43
Figure 3.15.: Notation: Multiple Activity Partition
3.5. Example Models
The example model scenario is equal to the examples of the Event-driven Process
Chains. Event-driven Process Chains from the Subsection 1.2 are transformed
into Activity Diagrams. Therefore, a home care providing company (HCPC)
and its processes are modeled again.
In the first model ”Home care order”, there are three actors involved: HCPC
Patient, HCPC Employee and HCPC Doctor. These are modeled with three
Activity Partitions which are modeled multi dimensional. In the Action ”Discuss
cost plan” both actors HCPC Employee and HCPC Patients are involved. In
the Actions ”Discuss Care Plan”, ”Plan the non-medical care” and ”Plan the
medical care” HCPC Doctor and HCPC Patient are involved. The Activity
Partitions can be modeled horizontally or vertically. The ”HCPC Patient” could
be included in the horizontal box and the other involved actors in the vertical
box. That Activity Diagram would equal to the Event-driven Process Chain
model in 2.4.
Unlike in Event-driven Process Chains, the decision and parallel flows do not
have to be joined back with a control node. In the model below, following the
Activity ”Discuss care plan”, a parallel flow is introduced by a Fork Node. The
Join Node however is optional, and could also be left out. Another difference to
Event-driven Process Chains is that in Activity Diagrams, edges (Control Flows)
can be labeled.
In the first model the process is described when a patient by HCPC for care
applies. Then a care and cost plan are decided. The costs of the care can be
taken from the state or the patient has to pay himself.
The second model (Figure 3.17) explains a usual ”Home care” process. HCPC
care taker prepares the service equipment and car, and drives to the patient.
When the patient is not at home, the home care taker contacts his/her relatives.
Figure 3.16.: Example Model 1: Home Care Order
44
45
When the home care activities are finished, they have to be documented and
sent to the company.
Figure 3.17.: Example Model 2: Home Care
The third model (Figure 3.18) shows the process “Home care activities“ in
detail. When the home care taker arrives at the patient a series of different care
activities are done. The medical care can be for example measuring the pulse
of the patient. When the medical and non-medical care activities are finished,
they have to be documented and sent to the company. After that the home care
taker can drive to the next patient.
Home Care Order
Home Care
Home Care Activities
Example models
in AD
Figure 3.16
Figure 3.17
Figure 3.18
Example models
in EPC
Figure 2.17
Figure 2.18
Figure 2.19
Table 3.1.: Example models in different business process modeling languages
In Table 3.1 an overview is given which Activity Diagram example model is
equal to which Event-driven Process Chain example mode. In the following section the mapping will be explained in detail.
Figure 3.18.: Example Model 3: Home Care Activities
46
47
Part III.
Transformation with Fujaba
48
This section explains the conceptual mapping of Event-driven Process Chains
to Acitvity Diagrams. First, mappings are described on an element-to-element
level. A simple 1:1 mapping is not possible, because the same element may be
mapped differently in a different context. For this reason, higher-level mapping
variants are also described. Therein, the mapping of several elements and their
relationship to each other (model fragments) is documented. These fragments
will later be implemented using Fujaba’s Triple Graph Grammar support.
4.1. Conceptual Element-to-Element Mapping
In this subsection possible transformation scenarios from Event-driven Process
Chain to Activity Diagram will be examined. Thereby, the scenarios will be
modeled conceptually without considering any transformation approach.
Elements of Event-Driven Process Chain
Basic Function
Complex Function
Event
Control Flow
Organizational Flow
Logical Operator “AND“
Logical Operator “OR“
Logical Operator “XOR“
Organizational Unit
Elements of Activity Diagram
Action
Call Behavior Action
Activity Edge, Initial Node,
Final Node
Activity Edge
Fork Node/ Join Node
Fork Node/ Join Node
Decision Node/ Merge Node
Activity Partition
Table 4.1.: Mapping from Event-driven Process Chain to Activity Diagram
Elements of Activity Diagram
Action
Call Behavior Action
Activity Edge
Initial Node
Activity Final Node
Flow Final Node
Merge/Decision Node
Fork/Join Node
Elements of Event-Driven Process Chain
Basic Function
Complex Function
2 x Control Flow, Event
Event without incoming Control Flow
Event without outgoing Control Flow
Event without outgoing Control Flow
Logical Operator “XOR“
Logical Operator “AND“, “OR“
Activity Partition
49
Organizational Unit
Table 4.2.: Mapping from Activity Diagram to Event-driven Process Chain
Table 4.1 and 4.2 show element-to-element mappings from Event-driven
Process Chain to Activity Diagram and vice versa.
A Basic Function and Complex Function are mapped to an Action and Call
Behavior Action and vice versa respectively. An Event and a Control Flow
is mapped to an Activity Edge, where the Event is mapped to the “name“
attribute of the Activity Edge. There are three logical operators in Event-driven
Process Chain and two corresponding control nodes. The logical operators
“AND“ and “OR“ are mapped to the same control node, namely Fork/Join
Node. The difference between “AND“ and “OR“ nodes is their handling of
guard expressions. If the guard expressions attached to the respective flows are
the same, “AND“ is used.
The Initial Node is mapped to Event-driven Process Chain as its first element,
which is always an Event. This Event has no incoming but an outgoing Control
Flow. The mapping of Final Nodes is exactly the opposite. They are again
mapped as Events, but in this case as last Event of the diagram, with no outgoing
Control Flow.
As the Activity Partition is modeled and illustrated as container element, the
Organizational Flow will not be mapped.
4.2. Mapping Variants
In this subsection simple element combinations in Event-driven Process Chains
and their transformation in Activity Diagrams will be shown in figures and
explained. This acts also as preparation for the Triple Graph Grammar rules
described later on.
The element of Event-driven Process Chain and Activity Diagram cannot
always be mapped directly. In most cases the exact transformation depends on
the context of the element to be transformed. For example an Event can be
mapped in several different ways because the predecessor and successor elements
have to be taken into consideration. Additionally to the one-to-one mapping
like described in tables 4.1 and 4.2 the elements themselves and their relations
will be mapped in the figures of this section. This is a useful preparation for
the definition of Triple Graph Grammar rules, because Triple Graph Grammar
rules also include not only the isolated elements, but their relationships to other
elements as well.
There are some assumptions made for the transformation of Event-driven
50
Process Chains and Activity Diagrams. The Activity Diagrams cannot have
multiple Initial Nodes. According to that, Event-driven Process Chains have one
start and one end Event. The transformations shown in this subsection and the
transformation rules in Section 5 are defined according to these assumptions.
In Figures 4.1, 4.2, 4.3, 4.4, 4.5, 4.6 and 4.7 Event-driven Process Chain model
fragments and their corresponding Activity Diagram sections are shown. Here,
the element Event from Event-driven Process Chain is seen as central point of
the model fragments. Based on that all possible combinations containing one
or more Events are listed. All diagram sections use Events as central elements,
with the exception of Figure 4.7, illustrating the use of Organizational Units.
Organizational Units only apply to Basic Functions, therefore no Event is used
in this fragment. Every possible Event-driven Process Chain my be constructed
using only the variants of the sections in the figures.
Variant 1 and 2 in Figure 4.1 my be interpreted together or separated.
Furthermore, it illustrates an Event before and after a Basic Function. These
cases are transformed to an Activity Diagram section where the Basic Functions
are mapped to Actions, Control Flows and Events are mapped to attributes
of Activity Edges. The names of the Events are set as guard expression of
the incoming and outgoing Activity Edges (name labeling on Activity Edges).
Variants 3, 4 and 5 in the same figure show the mapping of a Basic Function
followed by an Event and Logical Operator (“AND“, “OR“, or “XOR“) to an
Action followed by control nodes (Fork Node/Join Node, Decision Node/ Merge
Node).
In Figure 4.2 and 4.3 the cases involvoving logical operators (“AND“, “OR“,
or “XOR“) are considered. Both splitting and joining cases are shown. Here, the
logical operator “AND“, “OR“ or “XOR“ is between a Basic Function and an
Event. It is notable that the Events are mapped to outgoing Activity Edges from
the control node in Activity Diagrams. The name of the Event is again mapped
as guard expression of the Activity Edge.
Figure 4.1.: Sections from EPC and AD
51
Figure 4.2.: Sections from EPC and AD (2)
52
Figure 4.3.: Sections from EPC and AD (3)
53
54
Figure 4.4 illustrates the beginning of a diagram. Event-driven Process Chains
always start with an Event, Basic Functions are not allowed at the beginning. The
Event can be followed by a Basic Function or the logical operator “AND“. “XOR“
and “OR“ are not applicable, because Events cannot make a decision. However,
Activity Diagrams have a dedicated element, called Initial Node, which denotes
the beginning of the diagram. Therefore, Events without incoming Control Flows
are interpreted as beginning nodes and are mapped to Initial Nodes. The name
of the respective Event is also the name of the corresponding Initial Node. After
the Event, a Basic Function or a logical operator is possible [MK06].
Figure 4.4.: Sections from EPC and AD: Event to Initial Node
The opposite case is shown in Figure 4.5 and 4.6. Event-driven Process Chains
also have to end with an Event. Correspondingly, Activity Diagrams also have
a dedicated end node: Activity final node. (see Figure 4.5) Events without
outgoing Control Flows are mapped as Activity Final Nodes. Contrary to Initial
Nodes, all logical operators are allowed as predecessor of the last Event of the
diagram.
An Event without an outgoing Control Flow can also be mapped to flow final
node. This case is illustrated in Figure 4.6. For a distinction between the final
Figure 4.5.: Sections from EPC and AD: Event to Flow Final Node
55
Figure 4.6.: Sections from EPC and AD: Event to Activity Final Node
56
57
nodes of Activity Diagram some additional information has to be given to the
corresponding Event of the Event-driven Process Chain. In the examples in
this section and in the transformation rules in Section 5 of this master thesis,
such Events are named “FlowEnd“ to distinct final nodes when executing a
transformation between Event-driven Process Chains and Activity Diagrams.
In Figure 4.7, no Events are included, because Organizational Units only apply
to Basic Functions. One Organizational Unit can be connected to one or more
Basic Functions, and vice versa. The concept of this element is the same as
Activity Partitions in Activity Diagrams. However, there is no flow connection
between Activities and Activity Partitions, because the partitions contain the
Activities. The orientation (horizontal or vertical) of Activity Partitions is not
of importance.
Figure 4.7.: Sections from EPC and AD: Organizational unit to Activity Partition
The logical operator “AND“ and “OR“ are both mapped to Fork/Join Node.
To make a distinction between both logical operators the successor Events of
these logical operators have to be analyzed. As seen in Figure 4.8 the logical
operator “AND“ is followed by two Events with the same name (Event B) and
“OR“ is followed by two Events with different names. In this way a distinction
can be made when transforming from Activity Diagram to Event-driven Process
Chain. If “AND“ is also followed by two (or more) Events with different names
the distinction of both logical operators would not work.
58
Figure 4.8.: Sections from EPC and AD: Distinction between “AND“ and “OR“
59
This section provides an overview to Triple Graph Grammars. First, a comparison
to Pair Graph Grammars is given. After that, the mechanism of Triple Graph
Grammar Rules is explained.
5.1. Pair Graph Grammars versus Triple Graph
Grammars
The roots of triple graph grammars lead to “Pair Graph Grammars“, which were
introduced by Pratt in 1971 [Pra71]. Pair Graph Grammars define a mapping
between two subgraphs or a graph and a string within an overall graph. With
Pair Graph Grammars graph-to-string or graph-to-graph transformations may
be done. Each vertex of the source and target models is mapped directly, so
that only 1 to 1 mapping relationship may be executed. Each Pair Graph Grammar rule consists of two graph productions: A graph production and a string
graph production or two graph productions as source and target models [GGL05].
Figure 5.1.: Pair Graph Grammars versus Triple Graph Grammars
Triple Graph Grammars (TGG) were introduced in the early nineties by
Schürr [Sch95]. Schürr added a third subgraph to the transformation which is
called “Correspondence Graph“. In contrast to Pair Graph Grammars, TGGs
contain three graph productions. The two subgraphs in pair graph grammars act
60
as left and right side in triple graph grammars. The relationship between the left
and right graph is established through the correspondence graph, which is shown
in Figure 5.1. This correspondence graph enables to build n to m relationships
between graphs, where multiple nodes on the left side correspond to multiple
nodes on the right side. An example of this fact is the relationship of Events in
Event-driven Process Chains to Activity Edges. (One Activity Edge corresponds
to one Event and two Control Flows, see Section 4.)
5.2. Triple Graph Grammars Rules
Definition 5.1 (Triple Graph Transformation Rule) A triple graph transformation rule tgg = <plef t , pright , pmap > consists of three graph transformation
rules plef t , pright and pmap where plef t transforms the source model, pright transforms the target model and pmap transforms a relation model that maps source to
target elements. All three graph productions are applied simultaneously [GGL05].
The graph evolves gradually during the transformation using triple graph
grammar rules. The whole graph conforms to its schema at any time, as well
as the subgraphs involved on the left and right side. The correspondence graph
keeps track of the correspondences between the source and target graph nodes.
From a model transformation point of view, the correspondence subgraph stores
the traceability information. Triple graph grammars support bidirectional and
incremental model transformation because of the architecture involving the
correspondence subgraph [Kön05].
61
Figure 5.2.: Structure of a possible TGG rule
In Figure 5.2 a TGG rule is shown. Each TGG rule has a left and right
side. Here the elements that will be transformed are modeled. On the left side
the source model and its elements, on the right side, the target model and its
elements are placed. The middle of each TGG rule is the corresponding part. It
connects the elements of source and target model and maps them.
Model A in Figure 5.2 is the source model and Model B is the target model.
In the middle is the mapping part of the transformation (correspondence graph).
The element “A1“ is the root element of ModelA and the elements “A2“ and
“A3“ reference to it. On the right side of the transformation the element “B1“ is
the root element. The element “A1“ of ModelA is mapped to the element “B1“
of ModelB via the MappingNode “Cor1“. The MappingNode “Cor1“ contains
the tracing information of the elements “A1“ and “B1“.
62
Figure 5.3.: An example for a TGG rule
Figure 5.3 shows an example TGG Rule. It is based on mapping variant in Figure 4.4. The source graph conforms to Event-driven Process Chains, the target
graph to Activity Diagrams. Both are represented as graphs, with the source elements on the left side and the target elements on the right side. Additionally, the
correspondence graph is visible between the source and target graphs. The correspondence graph connects the related elements of the source and target graph. In
Figure 5.3 “Event“ is mapped to “Initial Node“ using the correspondence node
“Event2InitialNode“. The same applies to “Control Flow“ and “Activitiy Edge“,
and “Basic Function“ and “Action“. The relationships of the elements within a
distinct model are also modeled: “Events“ are connected to “Basic Functions“
via “Control Flows“ in the source model. ”Initial Nodes” are connected with an
”Action” by an ”Activity Edge”.
5.3. TGG Rule Algorithm
The algorithm of transforming the elements with TGG rules operates as follows
[Kön05]:
1. The algorithm starts with the root elements. These are the elements which
have no parents or are not in a composite relationship.
In case of executing model transformations between Event-driven Process
Chain and Activity Diagram the root elements are the diagrams themselves.
(see the meta models in Subsections 2.3 and 3.3).
2. For each Element e of the root elements, the set of TGG rules is identified
which handles a possible transformation of this element.
For example e is a “Control Flow“ from Event-driven Process Chains. Then
all the rules which contain the Control Flow are identified.
63
3. For each identified TGG rule, it is checked whether the model requires
another element created before e.
In order to create a Control Flow, a Basic Function and an Event have to
be created before.
4. If another element has to be created before, the transformation of e is
stopped and will be done after the required element is handled. This ensures
that the TGG rules are executed in the right order.
5. The whole process is repeated until no new output node is created by any
rule.
A summary about Triple Graph Grammars and Triple Graph Grammar Rules
is listed as conclusion in the following:
• Triple graph grammars are graphical and declarative.
• Triple graph grammars support incremental model transformation
• Triple graph grammar rules can be executed in both directions. (bidirectional model transformation)
• A triple graph grammar rule has always a source, a target and a correspondence part.
64
This section explains how Fujaba Plug-ins are developed. First, an introduction
to Fujaba in general is provided. After that, the different steps needed for implementing plug-ins are described. Also, source code examples are given, and
problems which may occur are documented.
6.1. Fujaba
Fujaba [Fuj07e] is an open source CASE (Computer Aided Software Engineering)
tool which is developed at the University of Paderborn since 1997. Now, the
development continues in cooperation with many other universities, among them
Darmstadt University of Technology and University of Kassel. Fujaba is an
abbreviation for “From UML to Java And Back Again“. Figure 6.1 shows an
overview to the interface of Fujaba.
Figure 6.1.: An overview of Fujaba
Fujaba is written in Java. Therefore it is platform independent. It has an
extendible architecture that provides the ability to add plug-ins. Fujaba supports
65
forward engineering as well as reverse engineering. Models may be created from
Java code, and retrieved (see Figure 6.2).
Fujaba provides the Unified Modeling Language (UML) formalism for designing software. It supports many UML diagrams such as Class Diagram, Statechart
Diagram, Package Diagram and Activity Diagram. Using them, structure and
behavior of a software system may be modeled.
Figure 6.2.: Import/Export menu of Fujaba
There are six Fujaba Projects, which are developed independently.
• Fujaba Tool Suite Reengineering: This project concentrates on design patterns recognition with Fujaba [Fuj07d].
• Fujaba Real-Time Tool Suite: This project is for the model-driven specification and development of embedded real-time systems. Real-time systems
are intended for real time applications. The real-time systems are specified
with component diagrams from UML, Real-time coordination patterns, and
Real-Time Statecharts. Component diagrams are needed to specify the architecture of the real-time systems and coordination patterns define the
real-time communication protocol. The behavior of a component or the
behavior of the roles of a real-time communication protocol are modeled by
a Real-Time Statechart. The models are checked for correctness and are
implemented by code generation [Fuj07b].
• Education: The education project called “Life“ is applied at secondary
schools to teach computer science to students. “Life“ is an abbreviation for
“Lernwerkzeuge für den Informatikunterricht: Einsetzen, Evaluieren und
(Weiter)Entwickeln“. In english, that means “Educational Tools for Computer Science Lessons: Apply, Evaluate and Develop (further)“ [Fuj07a].
• ISILEIT: ISILEIT is an abbreviation for “Integrative Specification of Distributed Control Systems for the Flexible Automated Manufacturing“. This
project aims at the development of a seamless methodology for the integrated
66
design, analysis and validation of distributed production control systems
[ISI07].
• Fujaba4Eclipse: Fujaba is also available as Eclipse plug-in [Fuj07f].
• TGG: TGG is an abbreviation for “Triple Graph Grammars“. This project
allows the user to execute model transformations using Triple Graph Grammars [Fuj07c].
6.2. Required Software for Triple Graph Grammars
It is required to install Fujaba Version 4.3.2. This is an old Fujaba 1 version,
but at the moment it is the only version that supports “MoRTEn”(Model
Round-Trip Engineering) and ”MoTE” (Model Transformation Engine) and
plug-ins, which are needed for Triple Graph Grammar Transformations. The
additional code for plug-in is written using the Eclipse framework but any other
Java development environment may be used.
6.3. Steps to build the Event-driven Process Chain
and Activity Diagram Plug-ins
Users should be able to create an Event-driven Process Chain and an Activity
Diagram with their basic elements. The elements included in these plug-ins
are those explained in the first part of the work. (see Section 2 and Section
3). Furthermore, Fujaba needs to be able to save and load the modeled diagrams.
The plug-ins are based on the “MyPlugin“ project from the Fujaba homepage
[Fuj07e]. The source code of ”MyPlugin” is available for download. It contains a
diagram type called “My Diagram” with only two basic elements: A node and an
edge. Two nodes may be connected by an edge. The user may choose between
different appearances of the elements; oval and rectangular. In Event-driven
Process Chains and Activity Diagrams, this feature is not needed, so it is ignored
when implementing the plug-in. The approach used during development of the
plug-ins is based on [Wen05]. This work provides a step by step description of
building a Fujaba plug-in.
6.3.1. Implementing the Plug-in Interface
The first step is to implement the plug-in interface. For this purpose the abstract
class “de.upb.lib.plugins.AbstractPlugin” is extended. This class is defined in
Fujaba‘s library. This class is also the entry point for the plug-in.
1
The current version is 5.0.4
67
Every Fujaba plug-in has to implement a main plug-in class. The most
convenient way is to simply extend the abstract plug-in class, but it is also
possible to implement the interface ”PluginInterface”, like seen in Figure 6.3.
Figure 6.3.: Implementing the plug-in interface for EPC
6.3.2. Defining the Meta Models
The next step is to define the meta models. Here, the meta model for Eventdriven Process Chain and Activity Diagram are created with Fujaba’s class
diagram editor. The meta models modeled in Fujaba for the plug-ins are equal
to those in 2.3 and 3.3.
The meta models have to be included in the plug-in .jar file created later.
Therefore, after the complete definition of the meta model Java code is generated.
Before generating code, the output path for the Java files has to be set in the
project’s preferences. This could be for example the location of the Eclipse
workspace. The code generation is started from the menu “Import/Export“,
“Export all classes to Java“.
The meta model classes are derived from Abstract Syntax Graph (ASG)
Classes, which are defined in the Fujaba‘s library. Fujaba’s ASG classes handle
many important aspects of diagram features, for example loading and saving of
models. Therefore it is recommended to simply extend these provided abstract
classes.
6.3.3. Connecting to Fujaba´s Meta Model
Here, the Event-driven Process Chain and Activity Diagram elements are
connected to Fujaba´s “UMLClass“ by using the “Meta Model Integration
68
Pattern“. For this, the meta models are extended.
6.3.4. Implementing the Actions
In this step the task is to implement Actions for creating and deleting each
Event-driven Process Chain and Activity Diagram element.
Listing 6.1: DeleteAction in Event-driven Process Chain plug-in
1
2 public class DeleteAction extends Abstractaction {
3
4
public void actionPerformed ( ActionEvent e ) {
5
6
Object source = e . getSource () ;
7
8
if ( source instanceof Iterator ) {
9
ASGElement element ;
10
for ( Iterator iter =( Iterator ) source ;
11
iter . hasNext () ; element . removeYou () )
12
element =( ASGElement ) iter . next () ;
13
} else {
14
ASGElement element =( ASGElement ) source ;
15
element . removeYou () ;
16
}
17
18
UMLProject . get () . refreshDisplay () ;
19
}
20 }
In Listing 6.1, ”DeleteAction” is shown. It is derived from Abstractaction,
as are the other implemented Actions. The object “source“ can contain either
a single element or an iterator over multiple elements. Depending on that, the
element or all elements contained in the iterator are removed with the method
removeYou. Then, the elements marked are deleted. Finally, the display is being
refreshed.
The ActionEvent is an instance of the class java.awt.event.ActionEvent.
This could for example be a click on a button. In this case the ActionEvent
contains the marked diagram elements at the time the Action occurred. If more
than one diagram element is selected the object contains an iterator over the
selected elements.
Listing 6.2: Adding a new FlowFinalNode as Action in Activity Diagram plug-in
1
2
3
public class N e w A D F l o w F i n a l N o d e A c t i o n extends
AbstractAction {
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25 }
69
public void actionPerformed ( ActionEvent bFunction ) {
Object source = bFunction . getSource () ;
ActivityDiagram myDiagram = null ;
if ( source instanceof ActivityDiagram )
{
myDiagram = ( ActivityDiagram ) source ;
}
else
{
source = UMLProject . get () . ge tCurre ntDiag ram () ;
if ( source instanceof ActivityDiagram )
{
myDiagram = ( ActivityDiagram ) source ;
}
}
FlowFinalNode myNode = new FlowFinalNode () ;
myDiagram . addToElements ( myNode ) ;
}
In Listing 6.2 a new Flow Final Node is added to the Activity Diagram.
Because the Flow Final Nodes may only be added to objects of the type Activity Diagram, it has to be ensured, that the source is of the type Activity Diagram.
6.3.5. Defining Concrete Syntax
The next step is defining the concrete syntax of the elements in the meta models.
A rendering class for each meta model element has to be implemented by
extending de.uni paderborn.fujaba.fsa.unparse.AbstractUnparseModule.
This Module describes how elements are drawn within a diagram.
Defining the different shapes of the elements is hard work. Many already
available classes may be used but in many cases it isnecessary to implement
these classes in order to create the desired appearance. Depending on the special
case this is done either by extending the AbstractColorBorder class or other
Swing classes such as JCircle.
Listing 6.3: Drawing a Border for an Event in EPC Plug-in
1
2
3
4
5
6
public class EPCEventBorder extends A bs t r ac t C ol o r Bo r d er {
...
public void paintBorder ( Component c , Graphics g , int x ,
int y , int width , int height )
{
Color oldColor = g . getColor () ;
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32 }
70
g . setColor ( getBorderColor () ) ;
int newX [] = new int [7];
int newY [] = new int [7];
newX [0] = x ;
newX [1] = x + ( width /5) ;
newX [2] = x + (4* width /5) ;
newX [3] = x + width -1;
newX [4] = x + (4* width /5) ;
newX [5]= x + ( width /5) ;
newX [6]= x ;
newY [0] = y +( height /2) ;
newY [1] = y ;
newY [2] = y ;
newY [3] = y + ( height /2) ;
newY [4] = y + height -1;
newY [5] = y + height -1;
newY [6] = y +( height /2) ;
g . setColor ( Color . PINK ) ;
g . fillPolygon ( newX , newY , 7) ;
g . setColor ( getBorderColor () ) ;
g . drawPolyline ( newX , newY , 7) ;
g . setColor ( oldColor ) ;
}
...
Listing 6.4: Using a EPCEventBorder for an Event in EPC Plug-in
1
2
3
public class UMEvent extends A b s t r a c t U n p a r s e M o d u l e {
4
5
6
7
8
9
10
11 }
public FSAObject create ( FSAObject parent ,
L o g i c U n p a r s e I n t e r f a c e incr ) {
Event psObject = ( Event ) incr ;
FSAPanel panel = new FSAPanel ( incr ,
getMainFsaName () , parent . getJComponent () ) ;
EPCEventBorder eventb = new EPCEventBorder () ;
panel . setBorder ( eventb ) ;
...
}
...
As an example, the Listings 6.3 and 6.4 illustrate how Events are drawn in
Event-driven Process Chain plug-in. The resulting shape looks like in Figure 6.4.
The class EPCEventBorder is extended from the class AbstractColorBorder,
which is defined in Fujaba´ s library and draws colored borders. An Event in
Event-driven Process Chains is shown as a hexagon shape. To draw it, seven
points in an imagined coordinate system are computed, depending on the size
and the location of the object. The first and the last points are the same,
so the shape is closed. After that a polygon is drawn and filled with color
71
Figure 6.4.: Import/Export menu of Fujaba
using the computed coordinates. The class EPCEventBorder is then used in the
UnparseModule to draw the desired hexagonal shape.
6.3.6. User Interface
In this part of the work, the task is to create an XML file named stable.xml with
the description of user interface extensions. First every Action implemented, as
described in 6.3.4, is defined. After that the menus, toolbars and popup menus
are built based on the definition of the actions.
Listing 6.5: A section from stable.xml of EPC Plug-in defining an Event’s icon
1 < Action id = ’ ’ EPCPlugin . Event ’ ’ class = ’ ’ at . selin . actions .
NewE PCEven tActio n enabled = ’ ’ true ’ ’ >
2
< Name > Create a new Event </ Name >
3
< Mnemonic >e </ Mnemonic >
4
< ToolTip > Create a new Event </ ToopTip >
5
< Icon > gifs_plugin / event . GIF </ Icon >
6 </ Action >
In the fragment of stable.xml file in Listing 6.5, the action “Create a new
Event“of the Event-driven Process Chains is defined. The Action id is used as
reference within the other sections of this xml file. The class attribute binds the
action to its implemented class as described in 6.3.4. A mnemonic and tooltip
may be supplied. The icons have to be saved as .gif with size 16*16.
Listing 6.6: A section from stable.xml of EPC plug-in defining the toolbar menu
1 < ToolBar id = " EPCDiagram . EPCToolBar " rolloverButtons = " true "
visible = " false " >
2
< ToolBarSection id = " EPCDiagram . EPCToolBar . newSection " >
3
< Button actionId = " EPCPlugin . Event " / >
4
< Button actionId = " EPCPlugin . ControlFlow " / >
5
< Button actionId = " EPCPlugin . Org an is at io na lF lo w " / >
6
< Button actionId = " EPCPlugin . BasicFunction " / >
7
< Button actionId = " EPCPlugin . OrganizationUnit " / >
8
< Button actionId = " EPCPlugin . And " / >
9
< Button actionId = " EPCPlugin . Or " / >
10
< Button actionId = " EPCPlugin . Xor " / >
11
< Button actionId = " EPCPlugin . Delete " / >
72
12
</ ToolBarSection >
13 </ ToolBar >
In Listing 6.6, the toolbar section is defined. Every button is connected to an
actionID, which is set at the beginning of the file.
Figure 6.5.: Menus of the EPC Plug-in
In the figure 6.5 the toolbar and the main menu section with its defined names
and icons are shown at a glance.
6.3.7. Implementing the Frame Decorator
This step defines how the GUI will look like when the diagrams are displayed.
The class EPCDiagramFrameDecorator is extended from the abstract class
de.uni paderborn.fujaba.app.FrameDecorator, which controls showing and
hiding its diagrams. Further the caption of the diagram pane is also set.
The Event-driven Process Chains and Activity Diagram tabs are declared as
a tree. Every created diagram is added as node on it. On the figure 6.6 the tabs
of the plug-ins are shown.
73
Figure 6.6.: tabs
6.3.8. Defining the Plug-in Description
In this step, XML files for the plug-ins are prepared to describe them. They
contain information about the implemented plug-ins such as its name, short
description, vendor, version, download location etc. as seen in Listing 6.7.
Listing 6.7: Plugin.xml of the Activity Diagram plug-in
1
2 < Plugin pluginClass = " at . selin . A c t i v i t y D i a g r a m _ E d i t o r " >
3
< Name > AD Plugin </ Name >
4
< Version major = " 0 " minor = " 8 " build = " 0 " / >
5
< PluginLib > ADPlugin . jar </ PluginLib >
6
< Source > http: // stud4 . tuwien . ac . at /~ e0226141 / ADPlugin .
zip </ Source >
7
< Kernel major = " 4 " minor = " 3 " revision = " 0 " / >
8
< Description >
9
< ShortDescription > AD Plugin </ ShortDescription >
10
< D et a i le d D es c r ip t i on > This is an Activity Diagram
plug - in . </ D et a i le d D es c r ip t i on >
11
< Vendor > Selin Altan </ Vendor >
12
< Contact > mailto:selin . altan@gmail . com </ Contact >
13
</ Description >
14 </ Plugin >
6.3.9. Deploying the Plug-in
In the last step the plug-ins have to be deployed. For this purpose, all the
implemented classes and the images are packed in a .jar file. Then the .jar , and
the XML files (plugin.xml and stable.xml) are copied to a new directory within
the Fujaba´s plugin directory.
6.3.10. What Features Are Supported in Both Plug-ins?
In the following a list of all supported features in both plug-ins are given:
74
• Creating an Event-driven Process Chain respectively an Activity Diagram.
• Both diagrams are shown in the menu.
• Adding elements to the diagrams.
• Connecting elements via connectors.
• Deleting elements.
• Saving the diagrams.
• Showing elements in the toolbar.
• Renaming the diagrams and its elements.
6.4. Problems Faced When Using Fujaba
Several problems occurred during the thesis and complicated the work with Fujaba.
• Sometimes diagrams, which for example are not needed anymore, cannot
be removed. This behavior cannot be reproduced. However, it may lead
to cluttered projects, in which it is not clear, which components are still
needed and which are not.
• Diagrams cannot be exchanged. Fujaba offers no import/export mechanism for diagrams or model elements. Besides that, Fujaba also uses an
proprietary storage format and does not rely on open standards like “XMI“
or “MOF“. This makes reusing of existing models difficult. The problem
may be somewhat circumvented by generating Java code from the models
and performing reverse engineering in another project.
• Insufficient heap space is set for the virtual machine. Therefore the program
runs out of memory. In this case open projects cannot be saved anymore.
The corresponding error message is shown in Figure 6.7.
75
Figure 6.7.: Out of memory error
The problem can be resolved by setting the maximum heap size when
starting Fujaba. This can be done using a batch file. As seen in the listing
below the heap size can be set to 256 megabyte.
Listing 6.8: Batch file for starting Fujaba with increased heap size
1 java - Xmx256m - jar fujaba . jar
It seems that Fujaba’s developers are aware of that problem, because it has
a memory monitoring feature built in. The current memory status may
even be seen always in the status bar at the bottom of the main window.
Additionally, a memory monitor is included, as may be seen in Figure 6.8
Figure 6.8.: Monitoring memory usage
6.4.1. Example Models in Fujaba
After the development of the Plug-ins, they may be used to create Event-driven
Process Chains and Activity Diagrams with Fujaba. Figure 6.9 is equal to the
example model described in 3.16 and Figure 6.10 is equal to 2.19.
Figure 6.9.: Example model: Home care order in AD
76
Figure 6.10.: Example model: Home care activities in EPC
77
78
7. Defining TGG Rules for Model
Transformation
The following plug-ins and projects are necessary for the transformation of Eventdriven Process Chains to Activity Diagrams and vice versa. All the plug-ins shown
in Figure 7.1 are saved as (.jar) archive files.
• EPC and Activity Diagram plug-ins: These two plug-ins are used to
create and edit the respective diagrams.
• TGG Editor: This plug-in can be downloaded using Fujaba´s plug-in
manager. With the TGG Editor, triple graph grammar rules may be defined
and edited.
Figure 7.1.: Required plug-ins for TGG rules
• The Fujaba model transformation project: It contains the triple
graph grammar rules with their story diagrams, correspondence meta
model, Event-driven Process Chains meta model and Activity Diagram
79
meta model.
The model transformation project used in this master thesis will be explained in Subsection 7.1 in detail.
• MoRTEn (Model Round-Trip Engineering) and MoTE (Model
Transformation Engine) plug- ins: They help to execute model transformations and are based on TGGs. MoTE is used by the TGG Editor to
transform TGG diagrams to story diagrams.
Story diagrams may be exported to Java classes which are stored in a jar
archive. This archive contains the rule generation catalog which is used by
MoRTEn to transform Event-driven Process Chains to Activity Diagram.
Figure 7.2 provides an overview of the correlation between the involved
plug-ins and files. First for Event-driven Process Chain and Activity Diagram
are created. This may be done in a separate Fujaba project or within the TGG
Rules Fujaba project. The Event-driven Process Chain and Activity Diagram
plug-ins are based on the code created from the meta models. The TGG rules
reside in a separate project which contains the meta models Event-driven Process
Chain, Activity Diagram and Correspondence. The TGG rule diagrams use
these meta models. Story diagrams are created from the TGG rules using the
MoTE Plug-in. From these story diagrams, Fujaba creates Java classes which
contain the implemented transformation rules. These classes are bundled in a
rule catalog .jar file. To perform a transformation Event-driven Process Chain
or Activity Diagram may be modeled using the respective plug-in. Via MoRTEn
plug-in and rule catalog file, the transformation may be executed.
7.1. Model Transformation Project
In the model transformation project “Correspondence Meta Model“, “MoTE
Meta model“, “MoTE Rules“, Event-driven Process Chain meta model, and
Activity Diagram meta model are saved as UML class diagrams. These are
needed, so that TGG diagrams for TGG rules may be edited. TGG rules have
also to be included in the model transformation project. These are created with
the TGG editor of Fujaba.
7.1.1. Correspondence Meta Model
The correspondence meta model holds the tracing information. That is the
mapping information between source and target model. Basically, “TGGNode“ is
sufficient for the transformation of the models. To achieve a better performance,
TGGNode may be extended. When executing the TGG rules only specific
Figure 7.2.: Overview of TGG support in Fujaba
80
81
subclasses of TGGNode are matched.
The transformation of Event-driven Process Chain to Activity Diagram does
only use TGGNodes as correspondence nodes. In Figure 7.3 three subclasses
CorrAxiom, CorrConnectable and CorrConnection are shown for demonstrational
purposes. TGGNode may also reference any number of other TGGNodes.
Figure 7.3.: Correspondence meta model
7.1.2. MoTE Meta Model
As shown in Figure 7.4, the MoTE meta model contains several classes and their
relationships which are necessary to execute a model transformation. For example the class TGGEngine is responsible for the transformation itself. For this
purpose it uses TGGMapping classes which themselves may either be TGGRules
or TGGAxioms. The latter are used as entry point for transformations.
In meta model of Event-driven Process Chain and Activity Diagram, all the
elements have to be extended from “Object“. The relationship between “Object“
and “TGGNode“ is important, so that the nodes of the left and right side may be
connected to mapping nodes. MoTE meta model is not transformation specific.
The same meta model is used for all TGG transformations.
82
Figure 7.4.: MoTE meta model
7.1.3. MoTE Rules
At the beginning of the transformation, the class diagram named “MoTE Rules“
has two reference classes “TGG Axiom“ and “TGG Rule“. Each time a story
diagram is generated from a TGG diagram, a TGG rule is added automatically
to “MoTE Rules“ diagram, as shown in Figure 7.5.
The TGGAxiom element points to the entry point of the TGG rules. The rule
“ED2AD“ is the first rule and all the other rules are extended from TGGRule
based on “ED2AD“.
83
Figure 7.5.: MoTE rules
7.1.4. Event-Driven Process Chain and Activity Diagram
Meta Model
The meta models shown in Figure 7.6 and 7.7 are basically equal to those
in Subsections 2.3 and 3.3, however some additions are necessary in order
to integrate the elements to Fujaba and MoTE meta model. It is important
creating the connection between “ASGElement“ and Event-driven Process
Chains elements, because Fujaba may only serialize “ASGElements“. Each
“MyEPCItem“ is an element of “EPCDiagram“ which is extended from “ASGElement“. “MyEPCItem“ is extended from “ASGElement“ which is derived
from “Object“. That means, all the modeled elements of the diagram are
“ASGElements“ and “Objects“. The “EPCDiagram“ is an “ASGElement“ and
an “ASGDiagram“. The same diagram schema applies for the Activity Diagram
meta model (see Figure 7.7).
84
Figure 7.6.: EPC meta model in the Fujaba model transformation project
Figure 7.7.: Activity Diagram meta model in the Fujaba model transformation
project
85
7.2. Defining Triple Graph Grammar Rules with
Fujaba´s TGG Editor
Fujaba does not support TGG editing in the basic configuration. Therefore the
plug-in “TGG editor“ (Triple Graph Grammar editor) has to be downloaded.
Then, a new project may be created which will contain the TGG rules themselves, meta models of diagrams involved and one for the correspondence model.
Alternatively, an existing project may be modified, in order to keep the correct
MoTE meta model.
First of all, the meta models of the Event-driven Process Chains and Activity
Diagrams, which were modeled during programming the plug-ins are imported.
Fujaba 4.3.2 does not have a model-exchange feature. Hence, the meta models
cannot be transferred. Nevertheless this version has ”Import Java files” feature
which enables reverse engineering of java classes and making them available in
the Fujaba project. By doing so, it is not necessary to create the meta models of
the plug-ins again. Moreover it is not possible that inconsistences between the
original and new meta model occur, because the new meta model is created from
the code based on the original meta model. However importing of java classes
does not always resolve relationships correctly, so it may be necessary to adjust
the created diagram. In some cases actual relationships are only interpreted as
simple attributes.
By means of the TGG editor, TGG rules conforming to the source meta model,
the correspondence meta model and the target meta model are defined [Fuj07e].
New objects as reference to the meta model classes are created. These objects are
marked with different stereotypes, to show to which part of the transformation
they belong. With the TGG editor, it is also possible to add additional information to source and target models. A mapping in a rule occurs element by element.
Hence, not all the elements and their relationships of a meta model have to be
mapped for a transformation. A subgraph of a given meta model may be mapped.
After the TGG rules are defined via the TGG editor, the “Story diagrams“ are
generated from them. For each TGG rule, three story diagrams are generated
automatically: A forward story diagram, a mapping story diagram and a reverse
story diagram.
Fujaba´s story diagrams have UML Activity Diagram character. Within
story diagrams the TGG rules are embedded and they show the Control Flow
of a transformation in the order of time. Story diagrams for example have an
Initial Node, which denotes the beginning of a transformation rule. From the
story diagrams Java code is generated. Then, the code has to be archived as
.jar file, so that it can be used as the TGG rule catalog in a transformation project.
86
Figure 7.8.: The first TGG rule
In Figure 7.8 a trivial TGG rule is shown. An Event driven Process Chain
is mapped to an Activity Diagram via the correspondence element TGGNode
“eventdrivenprocesschain2activitydiagram“. This TGG rule is the entry rule of
the transformation because it has no parent rules and is executed first.
The stereotypes <<left>> and <<right>> show the left and right side of
the transformation rule. In this work, the left side of all the transformation
rules show the elements of the Event-driven Process Chains, and the right
side the element of the Activity Diagrams. In the first rule both diagrams are
mapped. They are also elements, because in the meta models they are modeled as
root element nodes and have containment relationships to all other element nodes.
The middle element of the transformation rules is the mapping part and called
“correspondence element“. It is always marked with the stereotype <<map>>.
Here, the correspondence element is of the type “TGGNode“ which is modeled in
the MoTE meta model shown in Figure 7.4. A “TGGNode“ is a “TGGMapping“
element which is defined in Fujaba´s library for triple graph grammars.
With the stereotype <<create>> an element or a relationship is created.
Generally in triple graph grammar transformations with Fujaba the elements or
relationships which have this stereotype are marked green.
Furthermore, the stereotypes <<input>> and <<output>> are used. Each
rule has at least one element with <<input>> stereotype and one element with
<<output>> stereotype. The TGGNode is the output element of the transformation. The element with stereotype <<output>> enables the transformation
to be executed in both directions.
As depicted in Figure 7.9 “constraints“ may be added to elements as well.
“Negative“ means that the element is not allowed to exist for the rule to be
executed. The other constrains are not used during the transformation of the
Event-driven Process Chains between Activity Diagrams.
87
Figure 7.9.: Marking an element with stereotypes in a TGG rule
In Figure 7.10 the transformation of a “BasicFunction“ and an “Action“ is
shown. “BasicFunctions“ are elements of “EPCDiagram“ and “Actions“ are
elements of “ActivityDiagram“. “BasicFunction“ and “Action“ are marked
with the stereotype <<create>> because they are created in this rule. The
“EPCDiagram“ and “ActivityDiagram“ have already been created in the rule
shown in Figure 7.8, so that they are not marked with <<create>>. The
TGGNode named “basicf2action“ contains the tracing information between
the “BasicFunction“ and “Action“. When mapping from Event-driven Process
Chain to Activity Diagram, the name of the “Action“ is set to the name of the
“BasicFunction“.
In Figure 7.11 another trivial TGG rule is shown. On the left side the logical
operator “XOR“ is created as an element of “EPCDiagram“. On the right side
the “Decision Node“ is created as an element of “ActivityDiagram“. They are
also mapped via a TGGNode named “xor2decision“.
For the transformation of other logical operators to control nodes, and
Organizational Unit to Activity Partition, similar rules are prepared, as well.
When executing the TGG rules shown in Figures 7.10 or 7.11 only the nodes are
created. For their relationships and edges other more complex TGG rules have
to be modeled.
The case, when the logical operator XOR is followed by a Basic Function
and an Event is demonstrated in Figure 7.12 simplified without the TGG rule
syntax. On the Event-driven Process Chain side, an Event is preceded by a
Basic Function, and then followed by a logical operator XOR. On the left side it
can be seen, how the transformation of this case to an Activity Diagram would
look like. The Decision Node is followed by an Action. The Event is mapped as
label of the Activity Edge.
In Figure 7.13 this rule is depcited as a TGG rule. The Basic Function,
Figure 7.10.: TGG rule: Mapping between a Function and an Action
88
89
Figure 7.11.: TGG rule: Mapping between the logical operator “XOR“ and the
Decision Node
90
Figure 7.12.: Two possible diagram sections and their mappings
the Control Flows and, Event, logical operator “XOR“ are all elements of
EPCDiagram. The Event, and control flows are marked with the stereotype
<<create>> because they are used and created in this rule for the first time. On
the left side the elements of the ActivityDiagram are shown. Only the Activity
Edge is marked with <<create>> because the other elements had been already
created in other TGG rules (see Figure 7.10 and Figure 7.11).
In the meta model of the Event-driven Process Chains in Figure 7.6 there
are two relationships between a Function and a Control Flow. That is because
Control Flow and Event can have an incoming and an outgoing edge. The
same relationship is shown in Figure 7.7 in the meta model of Activity Diagram
between Activity Node and Activity Edge. In the TGG rule in Figure 7.13 these
relationships are used. The ControlFlow “src“ is the source Control Flow for
the BasicFunction “bf“ and target Control Flow for Event “event“. The second
ControlFlow is called “tgt“ and is the source control flow for the same Event
and target Control Flow for the logical operator XOR.
The Basic Function is mapped to the Action via the TGGNode “bf2action“.
Because multiple Basic Functions and Actions may exist, it is necessary to know
which elements correspond to each other. For this purpose, the correspondence
TGGNodes are used. Every TGGNode contains information on which source
element corresponds to which target element.
The Event “event“ and both Control Flows “src“ and “tgt“ are mapped to the
ActivityEdge “edge“ via TGGNode “event2edge“. Control Flows are not mapped
to elements of Activity Diagram elements because they do not have a corresponding model element. During the transformation from Event-driven Process
Chain to Activity Diagram a TGG Node is created as output. The created TGGNode stores the information, which Event is mapped to which Activity Edge.
Similar TGG rules are modeled for the logical operator “AND“ and “OR“ as well.
91
Figure 7.13.: TGG rule: Mapping between the Event and the Activity Edge
92
For the case of an Event followed by a Control Flow and then a Basic Function,
the TGG rule is similar to the rule in Figure 7.13. This time the source and the
target roles between Event, Control Flow and Basic Function are changed. Else,
the TGG rule remains the same.
The TGG rule modeled in Figure 7.15 is demonstrated in Figure 7.14 simplified. On the Event-driven Process Chain side the logical operator XOR is
followed by a Basic Function. On the Activity Diagram side it is shown how the
Activity Diagram section for such an Event-driven Process Chain section would
look like.
In the TGG rule in the Figure 7.15 both of the diagrams have three elements
which are mapped via three TGGNodes. The elements of EPCDiagram are the
logical operator XOR, a Control Flow and a Basic Function. The Control Flow
is marked with the stereotype <<create>> because a Control Flow between a
logical operator XOR and Basic Function is used and created for the first time
in this rule. On the right side of the TGG rule from the elements of Activity
Diagram only the Activity Edge is marked with <<create>> because of the
same reason. An Activity Edge between a Decision Node and an Action is used
and created for the first time.
The Control Flow is mapped to Activity Edge via the TGGNode “controlflow2edge“. It is marked with the stereotypes <<create>> and <<output>>
because this TGGNode is created for the first time and it stores the information
of output elements of the transformation. In the other TGG rules an Event is
mapped to an Activity Edge.
93
Figure 7.15.: TGG rule: Mapping between the logical operator “XOR“ and Decision Node (2)
94
In Figure 7.16 the start elements of an Event-driven Process Chain and an
Activity Diagram are demonstrated. The Event-driven Process Chain always
begins with an Event. The second element may be either a Basic Function or
the logical operator AND. Here, a Basic Function succeeds the first Event. For
this Event-driven Process Chain, the equal Activity Diagram is on the right side
of the Figure. Here is an Initial Node followed by an Action.
In Figure 7.17 the Event-driven Process Chain and Activity Diagram scenario
from Figure 7.16 is modeled as a TGG rule. Four elements of EPCDiagram
are necessary for the transformation. These are a Control Flow (“incoming“,
and “cf“), an Event and a Basic Function. The Event and one of the Control
Flows are created. They are marked with the stereotype <<create>>. The
elements of ActivityDiagram are an Initial Node, an Activity Edge and an
Action. The Event and its outgoing Control Flow is mapped to the Initial Node
and its outgoing Activity Edge. One of the differences to other rules is that the
name of the Event is mapped to the name of Initial Node. In TGG rules explained before the name of the Event was mapped to an Activity Edge as its label.
The Event in Figure 7.16 has an outgoing Control Flow and a Basic Function
has an incoming Control Flow. The relationships between these elements are
created in this rule. On the right side, the Initial Node has an outgoing Activity Edge which is mapped to the Control Flow of EPCDiagram. The Action is
mapped to the Basic Function and has an incoming Activity Edge. When transforming an Activity Diagram to Event-driven Process Chain, it is prevented with
a constraint that an Event has an incoming Control Flow. Note, that the first
Event of an Event-driven Process Chain cannot have an incoming Control Flow.
The Control Flow “incoming“ has therefore a “negative“ constraint. Elements
which have a “negative“ constraint are drawn with a “X“ symbol on themselves.
With this constraint it is ensured that Control Flow “incoming“ does not exist.
Furthermore, the diagram consistency is ensured.
Figure 7.17.: TGG rule: Mapping between the Event and Initial Node
95
96
In Figure 7.18 the end elements of a possible Event-driven Process Chain
and Activity Diagram are illustrated. An Event-driven Process Chain always
ends with an Event, whereas in an Activity Diagram a final node is used as
last element. Here, there are two mappings. A Basic Function is mapped to an
Action and the Event and its incoming Control Flow is mapped to an Activity
Edge and Activity Final Node.
In Figure 7.19 the TGG rule of the scenario in Figure 7.18 is shown. On the
Event-driven Process Chain side (left side of the rule) the Basic Function has
an outgoing Control Flow and this Control Flow is connected to an Event. The
Control Flow and Event are mapped via the TGGNode “event2edge“ to the
Activity Edge and Activity Final Node elements of the Activity Diagram. The
elements on the left side and right side of the rule which are mapped with this
TGGNode are all marked with stereotype <<create>>.
The names of the Event and Activity Edge have to be equal. Furthermore
it is checked if the name of the Event starts with the String “FlowEnd“. The
first 7 letters are checked with the method “subString“. In negative case, this
TGG rule is executed and during the transformation from Event-driven Process
Chain to Activity Diagram an Activity Final Node is created. In case that the
name of the Event begins with the String “FlowEnd“, a second TGG rule is
executed. Then, a Flow Final Node is created. Because Event-driven Process
Chains do not have explicit end-nodes, the concept of different flow and Activity
Final Nodes in Activity Diagrams cannot be mapped directly. Therefore, the
possibility to differentiate between them is made available via the name property
of Events. If an Event’s name begins with the string “FlowEnd“, it is interpreted
as Activity Final Node during the transformation.
The Control Flow “outgoing“ in this TGG rule has the constraint “negative“.
If the Event is the last element of the Event-driven Process Chain, an outgoing
Control Flow must not exist, which is reflected by the “negative“ constraint. So,
the diagram consistency is ensured.
97
Figure 7.19.: TGG rule: Mapping between an Event and Activity Final Node
98
7.2.1. Mapping of Fork/Join and Decision/Merge Nodes
In Event-driven Process Chains, the same elements, namely the available logical
operator elements, are used to start and end alternative control flows. However in
Activity Diagrams this is not the case. The start and end elements for alternative
flows are different, but share the same notation. For this reason, seperate rules
have to be created to deal with Fork Nodes and Join Nodes, and Decision Nodes
and Merge Nodes. The rules for Fork Node and Join Node, and also for Decision
and Merge Node are basically the same. The only difference between the rule
for the beginning and end node of a alternative flow is a rule constraint. For
Fork Nodes and Decision Nodes, the constraint specifies, that the corresponding
Event-driven Process Chain element has only one incoming Control Flow, and one
or more outgoing Control Flows. For Join Nodes and Merge Nodes, the exact
opposite is the case. The Logical Operator in the Event-driven Process Chain
must have one outgoing Control Flow, and one or more incoming Control Flows.
7.3. Java Project with Triple Graph Grammar Rules
When the rules are modeled with the TGG editor, story diagrams are generated
from them. After that Java code is generated from the story diagrams. Additionally, an XML File has to be created manually which contains the configuration
information of the rules.
Listing 7.1: A section from “configuration.xml“ of the TGG rules in rule.jar
1 < configuration >
2
< triggertable >
3
< entry trigger = " " rule = " de . upb . mote . rules . ED2AD " / >
4
< entry trigger = " de . upb . mote . tgg . TGGNode " rule = " de .
upb . mote . rules . B a s i c F u n c t i o n 2 A c t i o n " / >
5
upb . mote . rules . AND2Fork " / >
6
upb . mote . rules . OR2Fork " / >
7
upb . mote . rules . XOR2Decision " / >
8
upb . mote . rules . C o nt r o lF l o wX O R 2E d g e " / >
9
upb . mote . rules . Co nt ro lF low An dE dg e " / >
10
upb . mote . rules . Event2EdgeVar1 " / >
11
upb . mote . rules . E v e n t 2 I n i t i a l N o d e V a r 1 " / >
12
upb . mote . rules . E v e n t 2 I n i t i a l N o d e V a r 2 " / >
13
upb . mote . rules . E ventAN D2Edge Var1 " / >
14
15
16
17
18
19
20
21
99
upb . mote . rules . E ventAN D2Edge Var2 " / >
...
</ triggertable >
< dependencies >
< plugin class = " at . selin . epc . EPC_Editor " major = " 1 "
minor = " 2 " / >
< plugin class = " at . selin . akdi . A c t i v i t y D i a g r a m E d i t o r "
major = " 1 " minor = " 0 " / >
</ dependencies >
</ configuration >
In the configuration.xml file, each TGG rule class and its dependencies are
listed. The dependencies are the Event-driven Process Chain and Activity
Diagram plug-ins which are needed for the model transformation.
During code generation for each rule a forward, mapping and reverse method
is written. When executing the rules, all elements from a given type are stepped
through. With the method “ensure“ several properties are proved. For example
a particular model element has a association with an other model element.
Listing 7.2: A section from the forward method of the rule ED2AD
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
public class ED2AD extends TGGAxiom {
public TGGNode forward ( Object source )
{
ActivityDiagram activitydiagram = null ;
boolean fujaba__Success = false ;
EPCDiagram epcdiagram = null ;
Iterator f u j a b a _ _ I t e r E n g i n e H a n d l e d A c t i v i t y d i a g r a m =
null ;
java . lang . Object fu jaba__ TmpObj ect = null ;
java . lang . Object f u j a b a _ _ t m p T y p e C a s t O b j e c t = null ;
TGGEngine engine = null ;
TGGNode epc2ad = null ;
TGGNode epc2adNew = null ;
...
while ( !( fujaba__Success ) &&
f u j a b a _ _ I t e r E n g i n e H a n d l e d A c t i v i t y d i a g r a m . hasNext
() )
{
try
{
fuj aba__T mpObje ct =
fujaba__IterEngineHandledActivitydiagram
. next () ;
JavaSDM . ensure ( fu jaba__ TmpObj ect
instanceof ActivityDiagram ) ;
20
100
activitydiagram = ( ActivityDiagram )
fuj aba__T mpObje ct ;
JavaSDM . ensure ( epc2ad . hasInTargets (
activitydiagram ) ) ;
activitydiagram . setName ( epcdiagram . getName
() ) ;
fujaba__Success = true ;
}
21
22
23
24
25
26
27
28
29
30
31
32
}
...
try
{
fujaba__Success = false ;
f u j a b a _ _ t m p T y p e C a s t O b j e c t = source ;
JavaSDM . ensure ( f u j a b a _ _ t m p T y p e C a s t O b j e c t
instanceof EPCDiagram ) ;
epcdiagram = ( EPCDiagram )
fujaba__tmpTypeCastObject ;
engine = this . getEngine () ;
JavaSDM . ensure ( engine != null ) ;
JavaSDM . ensure ( !( engine . hasInHandled ( epcdiagram
)) ) ;
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55 }
epc2adNew = new TGGNode ( ) ;
activitydiagram = new ActivityDiagram ( ) ;
activitydiagram . setName ( epcdiagram . getName () ) ;
epc2adNew . addToTargets ( activitydiagram ) ;
epc2adNew . addToSources ( epcdiagram ) ;
this . a d d T o C r e a t e d C o r r N o d e s ( epc2adNew ) ;
engine . a d d T o C o r r e s p o n d e n c e N o d e s ( epc2adNew ) ;
engine . setRoot ( epc2adNew ) ;
engine . addToHandled ( activitydiagram ) ;
engine . addToHandled ( epcdiagram ) ;
}
catch ( JavaSDMException f u j a b a _ _ I n t e r n a l E x c e p t i o n )
{
fujaba__Success = false ;
}
...
For each rule about 1000 lines of Java code are generated. In the listing above a
code section from the rule file is shown. This rule is the entry rule and modeled
in Subsection 7.8.
101
Additionally, a code fragment creating the target model is shown. After all
needed model elements are identified, and the constraints necessary are evaluated,
the target element is instantiated. Also, a new TGGNode is created. After that,
the links between the elements (TGGNode, Activity Diagram, ...) are established.
7.4. Lessons learned
During modeling the transformation rules with Fujaba´s TGG editor a few
problems have occurred. It is not possible to establish the bidirectional model
transformation of the logical operator “OR“ to control node Fork Node with
TGG rules in Fujaba. The transformation from Event-driven Process Chain
to Activity Diagram is straight forward. The logical operator “OR“ has to be
mapped to a Fork Node via a TGGNode. But such a rule would not work in
reverse direction (transformation from Activity Diagram to Event-driven Process
Chain) and the whole transformation would terminate. A collusion would occur
between this rule and the rule “AND2Fork“ where a Fork Node is mapped to the
logical operator “AND“. The Fujaba´s TGG rule engine cannot decide whether
the logical operator AND or OR should be set. The collusion cannot be solved
with TGG rules of Fujaba which have to be modeled bidirectional. However,
this results of the fact that three different operators cannot be mapped to two
different operators without loss of information.
Another problem occurs during the transformation of Organizational Units to
Activity Partitions. In case there is one Organizational Unit in an Event-driven
Process Chain or one Activity Partition in an Activity Diagram, model transformation is executed without having any problem. The Activity Partition is
a special element which may be modeled multidimensionally. Modeling of an
Activity Partition is a design matter. The TGG rules cannot decide how to
set the lines of the Activity Partition, so that the transformation of multiple
Organizational Units to Activity Partitions would not work correctly.
102
8. Evaluation of Triple Graph
Grammars with Fujaba
In this section, the evaluation of Triple Graph Grammars with Fujaba is conducted. A list of criteria is defined, and Triple Graph Grammar’s support for them
is discussed. Eventually, a conclusion is given, which points out the strengths and
weaknesses of Triple Graph Grammars.
8.1. Criteria Catalog
In this subsection the criteria for evaluating Triple Graph Grammars with Fujaba
are defined. Except for “Maintenance“, “Usability“ and “OCL Support“ the
criteria are based on the work of Czarnecki and Helsen [CH06].
Criteria
Approach
Rule Organization
Rule Application Control
Application Conditions
Syntactic Separation
Traceability Support
Incrementality
Directionality
Consistency Checking
Maintenance
Usability
TGG with Fujaba
Model-to-Model
Declarative, Graph based
Independent Organization
No Reuse or Modularity
Implicit scheduling, One Phase
No Rule Iteration
Implicit and Explicit
Source Model on the Left Side
Target Model on the Right Side
Manual Creation
Separate Location
Target Incrementality
No Source Incrementality
Bidirectional Model Transformation
Meta Model based
Not Intuitive
Rules Get Complex Easily
No (meaningful) Error Messages
Less Documentation, No Reuse of the Rules
Table 8.1.: Criteria Catalog
103
8.1.1. Approach
One major distinction between different model transformation languages is their
general approach. Declarative and imperative (also called operational) are the
the two most commonly used. The main difference between these two approaches
is their point of view concerning the transformation. Declarative approaches
concentrate on the “What“ aspect of the transformation. The developer specifies
what the transformation has to accomplish but does not specify exactly how this
has to be done, whereas imperative approaches concentrate on the “How“ aspect
[MCG05]. In practice many languages support both declarative and imperative
constructs, taking advantage of the according strengths, and are therefore called
hybrid languages.
Triple Graph Grammars are graph based and therefore declarative. The
“What“ aspect of the transformation is specified graphically. Graph based
means that the models involved are interpreted as in a graph theoretical way.
Graphs may easily be represented visually.
Moreover with TGG model-to-model transformation can be executed. In
this master thesis, an Event-driven Process Chain model is transformed to an
Activity Diagram model and vice versa.
8.1.2. Rule Organization
Rule organization my be divided into three subcriteria: Modularity mechanisms,
Reuse mechanisms and organizational structure [CH06].
A transformation approach which supports modularity mechanisms packages
transformation rules into modules. Triple Graph Grammars with Fujaba does
not support this feature. The TGG rules cannot be grouped.
The TGG rules cannot be used in a classical object oriented way with method
calls, which means they cannot call each other. If a TGG rule is needed in another rule, it has to be modeled again. In that case the stereotype <<create>>
is not used. All the elements in a TGG rule which do not have this stereotype
are defined and created in another rule and are used again. But such a reuse
mechanism does not simplify the modeling of transformations. A rule inheritance
or derivation between two TGG rules is not possible.
Triple Graph Grammars have an independent rule organization. TGG rules
are not organized according to the structure of the source or target model
[CH06]. They are organized according to their meta models.
104
8.1.3. Rule Application Control
This feature may also be called “rule scheduling“. It describes in which order
and how the TGG rules may be executed.
Triple Graph Grammars with Fujaba has an implicit scheduling. This means
the user cannot manipulate in which order the rules are executed. TGG rules
are performed until no rule creates output elements. Subsection 5.3 explains how
the rule algorithm of the TGGs with Fujaba is working.
A TGG rule cannot have recursion or looping. (No rule iteration mechanisms)
Additionally, the transformation process cannot be divided into multiple phases.
During the execution of the rules, the TGG engine cannot select a group of rules
to perform.
8.1.4. Application Conditions
Application Conditions are conditions, which may be attached to rules. The rule
is executed, when this condition is true.
Triple Graph Grammars with Fujaba support this feature in two ways. Implicit
application conditions are set by the layout of the transformation rule itself.
Because the rule itself contains a sub-model of a possible input model, the rule
is only executed, if the input model matches this sub-model. For example, a
rule containing a Basic Function connected to an Event with a control flow is
only executed, if the input model also has model elements complying to the submodel specified in the rule. Furthermore, explicit application conditions may be
set using side constraints.
8.1.5. Syntactic Separation
Syntactic Separation means that within a rule a clear distinction is made between
source and target model ([CH06]). In case of Triple Graph Grammars this is
done by the separation into left side and right side. They are marked with either
<<left>> or <<right>> stereotypes.
8.1.6. Traceability Support
In model transformation languages, tracing allows to find out, which target
elements have been created from which source elements and vice versa. The
correspondence graph in TGG rules is responsible for tracing support. It keeps
track of the correspondences between the source and target graph nodes. The information which source element is mapped to which target element is stored here.
In Triple Graph Grammars with Fujaba the tracing feature is created manually
because the correspondence graph has to be modeled explicit when defining the
105
TGG rules.
Moreover, the traceability information is stored separate in the correspondence
graph and not in source or target model. This avoids disorder in the models and
results in a better overview.
8.1.7. Incrementality
Target-incrementality means, that the target model is not completely recreated
when the transformation is run multiple times. Only changes in the source
model are newly generated. Source-incrementality means, that only the changes
in the source model are analyzed during a further transformation. Elements,
which have not changed, are not considered. Both of these types speed up the
transformation when running multiple times.
Triple Graph Grammars in Fujaba support only target-incrementality. Existing target elements are not overwritten. The TGGEngine only creates new
model elements. Source-incrementality is not supported, every run re-reads the
complete source-model.
8.1.8. Directionality
Directionality refers to whether a transformation can be performed only from
source to target, or also from target to source. With triple graph grammars
model-to-model transformation in both directions can be executed. That means
a transformation from source model to target model and from target to source
model are both possible.
The transformation from a source model to a target model in Fujaba is called
“forward transformation“ and the transformation from target model to source
model is called “reverse transformation“. The model elements in TGG rules
with Fujaba which are mapped with the stereotype <<left>> point to source
model, and the elements with stereotype <<right>> point to target model.
8.1.9. Consistency Checking
Consistency Checking ensures that a transformation always produces syntactically correct output models which conform to their respective meta model. The
source and target model of the TGG rules have to be conform to their meta
models. When defining the TGG rules with Fujaba it is not allowed to use elements or relationships which are not defined in the according meta model before.
In Figure 8.1 a TGG rule section shows the consistency checking feature
of Triple Graph Grammars with Fujaba. Here, two elements of Event-driven
106
Process Chain and their relationship are created. According to the meta
model, an Event and a Control Flow have (see Subsection 7.6) two associations,
(CF2Etarget and CF2Esource) because an Event may have one incoming and one
outgoing Control Flow. When defining a TGG rule, only these two associations
from the meta model may be selected as a link between an Event and a Control
Flow. In this way, model consistency is ensured.
Figure 8.1.: A section from a TGG rule
8.1.10. Maintenance
A basic TGG rule consists of a source graph, a correspondence graph and a
target graph element. Such a rule is easy to understand. But the TGG rules
tend to get too complex with more detailed models and it is difficult for the user
to understand them.
To avoid hard to understand TGG rules, the user should document every
modeled rule as help for other users and for later purposes.
8.1.11. Usability
Fujaba as tool offers good usability. As Figure 8.2 shows, the menus are well
arranged and are not overcrowded. The location of the menu points, toolbar and
messagebar are similar to other modeling tools like Visio [Vis] or Magic Draw
[Mag07].
107
Figure 8.2.: Overview to Fujaba
Fujaba is poorly documented. For example, TGGdiagram and model transformation is only covered in a short handbook, where many important aspects are
missing. A new user has to waste much time to master specific tasks like defining
a TGG rule. There are mailing lists for users of Fujaba where the developers
reply the questions immediately.
Specific for the TGG project of Fujaba, a big problem is that the TGG
rules cannot be reused in other rules. This makes the rules more complex
and not intuitive. A copy paste functionality would be very useful so existing
transformation parts may be reused more easily.
8.2. Lessons learned
Basically, Triple Graph Grammars in Fujaba are well suited for the transformation
of business process models. It is possible to transform most of the elements.
However some problems have occurred and are discussed in the following:
• Mapping of Logical Operators to Control Nodes: Like explained in Subsection 7.4 Logical Operators “AND“ and “OR“ are mapped to the same
Control Node. During the transformation from Activity Diagram to EventDriven Process Chain the “TGGEngine“ cannot decide whether to transform it to an “AND“ or “OR“ for a Fork Node because the information for
that is missing.
• Mapping of Organizational Units to Activity Partition: When a Basic Function is connected to three different Organizational Units it is not possible
108
to map it correctly when multi dimensional Activity Partitions are used.
An Action may only be contained in no more than two multidimensional
Activity Partitions. (see 7.4)
• Sparse documentation makes defining the TGG rules difficult. On the other
side the developers and mailing lists are very helpful.
• Fujaba has no XMI import and export functionality. It uses a proprietary
file format for its project files. Parts of a Fujaba project for example meta
model diagrams also may not be exported or imported. This is a considerable shortcoming because it restricts interoperabilitiy with existing models
and other tools.
Finally, following remarks are notable on the positive side:
• TGG rules are very intuitive if the rules are not too complex. Its graph
based visual approach allows to follow and understand the according rule
at a glance. It also visualizes parts of the meta models involved and how
they relate to each other.
• The marking with the stereotype <<create>> and the coloring of these
elements also enables a quick overview of which elements are generated by
the rule.
• Fujaba is an open source tool and is written in Java. Therefore it is platform
independent. Moreover it has an extendible architecture. Additional plug
ins may be developed easily. This thesis has positively profited from this
feature because modeling and transformation have been done in the same
application.
109
9. Conclusion
This section provides the conclusion of this master thesis and gives further outlook.
9.1. Summary
In the first part of this thesis, both business process modeling languages used for
the transformation, Event-driven Process Chains und Activity Diagrams, have
been introduced. Their respective history and context is brought to attention.
After that, all modeling elements are described, including their graphical notation and semantic meaning.
For preparing purposes, element mappings for Event-driven Process Chains
and Activity Diagrams are introduced. Additionally, mapping variants are
defined, which expand the context from one particular model element to several
elements in relationship to each other. This is useful, because one single element
in one language is not always mapped to exactly one element in the other
language. The exact mapping depends on the context of the particular element
to be mapped. Therefore, all possible combinations of elements and their
mapping are listed.
After that, the model transformation approach used in this thesis, namely
Triple Graph Grammars, is introduced. The history and mechanism of Triple
Graph Grammars are explained. A general algorithm describing how Triple
Graph Grammar rules are executed is explained. This section is also toolindependent and does not include technical details on Fujaba’s Triple Graph
Grammar implementation.
Because Fujaba does not support both business process languages used in this
thesis, plug-ins for them have to be developed. Section 6 explains in detail, which
steps are needed and how the plug-ins are developed. Furthermore, possible
problems which may occur during the development are discussed.
The next Section 7 explains how a particular transformation may be defined
using Fujaba’s Triple Graph Grammar support. All requirements, such as meta
models needed, are explained. An overview of how all needed components
collaborate is given. Furthermore, several rules of the transformation of Eventdriven Process Chains to Activity Diagrams, and the problems faced during their
creation are explained.
9. Conclusion
110
Eventually, several high-level criteria are listed and evaluated in respect of their
support in Triple Graph Grammar Rules using Fujaba. Finally, an overview of
the strengths and weaknesses of the described model transformation approach for
its suitability for business process models is given.
9.2. Future Work
This master thesis addresses the topic of model transformation for business
processes. First, two business process modeling languages are used. Therefore,
further work may also include other languages. From Event-driven Process
Chains and Activity Diagrams, the control and organizational aspects have been
used. A few restrictions are made. For example, only one Initial Node and
Final Node is allowed in the example diagrams. These restrictions may also be
addressed in future work.
Triple Graph Grammar have been used as transformation approach in this
thesis. Several other approaches exist in this area, which may also be evaluated
concerning their usefulness for transforming business process models.
111
List of Abbreviations
AD . . . . . . . . . . . . .
BPEL . . . . . . . . . .
BPMN . . . . . . . . .
EPC . . . . . . . . . . .
OMG . . . . . . . . . .
TGG . . . . . . . . . . .
UML . . . . . . . . . . .
Activity Diagram
Business Process Execution Language
Business Process Modeling Notation
Event-driven Process Chain
Object Management Group
Triple Graph Grammars
Unified Modeling Language
112
List of Figures
1.1. Different Model Transformation Scenarios, taken from [MKM06] .
1.2. Focus of this thesis . . . . . . . . . . . . . . . . . . . . . . . . . .
13
16
2.1. Event-driven Process Chain meta model .
2.2. Notation: Basic Function . . . . . . . . . .
2.3. Notation: Complex Function . . . . . . . .
2.4. Notation: Event . . . . . . . . . . . . . . .
2.5. Notation: The logical operator “AND“ . .
2.6. The logical operator “AND“ splits . . . . .
2.7. The logical operator “AND“ joins . . . . .
2.8. Notation: The logical operator “OR“ . . .
2.9. The logical operator “OR“ splits . . . . . .
2.10. The logical operator “OR“ joins . . . . . .
2.11. Notation: The logical operator “XOR“ . .
2.12. The logical operator “XOR“ splits . . . . .
2.13. The logical operator “XOR“ joins . . . . .
2.14. Notation: Organizational Unit . . . . . . .
2.15. Notation: Control Flow Connector . . . .
2.16. Notation: Organizational Flow Connector
2.17. Example Model 1: Home Care Order . . .
2.18. Example Model 2: Home Care . . . . . .
2.19. Example Model 3: Home Care Activities .
21
22
22
23
23
24
24
24
25
25
25
26
26
26
27
27
29
30
31
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3.1. Activity Diagram meta model . . . . . . . . . . . . . . . . . . . .
3.2. Notation: Action Node . . . . . . . . . . . . . . . . . . . . . . . .
3.3. Notation: CallBehavior Action . . . . . . . . . . . . . . . . . . . .
3.4. Notation: Initial Node . . . . . . . . . . . . . . . . . . . . . . . .
3.5. Notation: Flow Final Node . . . . . . . . . . . . . . . . . . . . . .
3.6. Notation: Activity Final Node . . . . . . . . . . . . . . . . . . . .
3.7. Notation: Decision Node . . . . . . . . . . . . . . . . . . . . . . .
3.8. Notation: Merge Node . . . . . . . . . . . . . . . . . . . . . . . .
3.9. Example for using Decision and Merge Node . . . . . . . . . . . .
3.10. Notation: Fork Node . . . . . . . . . . . . . . . . . . . . . . . . .
3.11. Example for “Guard Expressions“ in correlation with Control Nodes
3.12. Notation: Join Node . . . . . . . . . . . . . . . . . . . . . . . . .
3.13. Notation: Activity Edge . . . . . . . . . . . . . . . . . . . . . . .
3.14. Notation: Activity Partition . . . . . . . . . . . . . . . . . . . . .
3.15. Notation: Multiple Activity Partition . . . . . . . . . . . . . . . .
3.16. Example Model 1: Home Care Order . . . . . . . . . . . . . . . .
3.17. Example Model 2: Home Care . . . . . . . . . . . . . . . . . . . .
36
37
38
38
39
39
39
40
40
40
41
41
42
42
43
44
45
List of Figures
113
3.18. Example Model 3: Home Care Activities . . . . . . . . . . . . . .
46
4.1.
4.2.
4.3.
4.4.
4.5.
4.6.
4.7.
4.8.
51
52
53
54
55
56
57
58
Sections from EPC and AD . . . . . . . . . . . . . . . . . . . . .
Sections from EPC and AD (2) . . . . . . . . . . . . . . . . . . .
Sections from EPC and AD (3) . . . . . . . . . . . . . . . . . . .
Sections from EPC and AD: Event to Initial Node . . . . . . . . .
Sections from EPC and AD: Event to Flow Final Node . . . . . .
Sections from EPC and AD: Event to Activity Final Node . . . .
Sections from EPC and AD: Organizational unit to Activity Partition
Sections from EPC and AD: Distinction between “AND“ and “OR“
5.1. Pair Graph Grammars versus Triple Graph Grammars . . . . . .
5.2. Structure of a possible TGG rule . . . . . . . . . . . . . . . . . .
5.3. An example for a TGG rule . . . . . . . . . . . . . . . . . . . . .
59
61
62
6.1. An overview of Fujaba . . . . . . . . . . . . .
6.2. Import/Export menu of Fujaba . . . . . . . .
6.3. Implementing the plug-in interface for EPC .
6.4. Import/Export menu of Fujaba . . . . . . . .
6.5. Menus of the EPC Plug-in . . . . . . . . . . .
6.6. tabs . . . . . . . . . . . . . . . . . . . . . . .
6.7. Out of memory error . . . . . . . . . . . . . .
6.8. Monitoring memory usage . . . . . . . . . . .
6.9. Example model: Home care order in AD . . .
6.10. Example model: Home care activities in EPC
.
.
.
.
.
.
.
.
.
.
64
65
67
71
72
73
75
75
76
77
Required plug-ins for TGG rules . . . . . . . . . . . . . . . . . .
Overview of TGG support in Fujaba . . . . . . . . . . . . . . . .
Correspondence meta model . . . . . . . . . . . . . . . . . . . . .
MoTE meta model . . . . . . . . . . . . . . . . . . . . . . . . . .
MoTE rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
EPC meta model in the Fujaba model transformation project . .
Activity Diagram meta model in the Fujaba model transformation
project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.8. The first TGG rule . . . . . . . . . . . . . . . . . . . . . . . . . .
7.9. Marking an element with stereotypes in a TGG rule . . . . . . . .
7.10. TGG rule: Mapping between a Function and an Action . . . . . .
7.11. TGG rule: Mapping between the logical operator “XOR“ and the
Decision Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.12. Two possible diagram sections and their mappings . . . . . . . . .
7.13. TGG rule: Mapping between the Event and the Activity Edge . .
7.15. TGG rule: Mapping between the logical operator “XOR“ and Decision Node (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.17. TGG rule: Mapping between the Event and Initial Node . . . . .
7.19. TGG rule: Mapping between an Event and Activity Final Node .
78
80
81
82
83
84
7.1.
7.2.
7.3.
7.4.
7.5.
7.6.
7.7.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
84
86
87
88
89
90
91
92
93
94
95
96
97
List of Figures
114
8.1. A section from a TGG rule . . . . . . . . . . . . . . . . . . . . . . 106
8.2. Overview to Fujaba . . . . . . . . . . . . . . . . . . . . . . . . . . 107
115
List of Tables
3.1. Example models in different business process modeling languages
45
4.1. Mapping from Event-driven Process Chain to Activity Diagram .
4.2. Mapping from Activity Diagram to Event-driven Process Chain .
48
49
8.1. Criteria Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
116
List of Listings
6.1.
6.2.
6.3.
6.4.
6.5.
6.6.
6.7.
6.8.
DeleteAction in Event-driven Process Chain plug-in . . . . . . . .
Adding a new FlowFinalNode as Action in Activity Diagram plug-in
Drawing a Border for an Event in EPC Plug-in . . . . . . . . . .
Using a EPCEventBorder for an Event in EPC Plug-in . . . . . .
A section from stable.xml of EPC Plug-in defining an Event’s icon
A section from stable.xml of EPC plug-in defining the toolbar menu
Plugin.xml of the Activity Diagram plug-in . . . . . . . . . . . . .
Batch file for starting Fujaba with increased heap size . . . . . . .
7.1. A section from “configuration.xml“ of the TGG rules in rule.jar .
7.2. A section from the forward method of the rule ED2AD . . . . . .
68
68
69
70
71
71
73
75
98
99
117
Bibliography
[Alt07]
Altova Umodel, 2007. http://www.altova.com/.
[Ari]
Aris Software. http://www.ids-scheer.com.
[Art07]
Artisan Studio 6.1, 2007. http://www.artisansw.com/.
[Boc05]
Adonis 3.7, 2005. http://www.boc-group.com.
[bpe07]
Web services business process execution language version 2.0, 2007.
http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.pdf.
[bpm06]
Business process modeling notation specification, 2006. http://www.
omg.org/docs/dtc/06-02-01.pdf.
[CH06]
K. Czarnecki and S. Helsen. Feature-based survey of model transformation approaches, 2006.
[Dav93]
T. Davenport. Process innovation - reengineering work through information technology. Harvard Business School Press, 1993.
[Dij72]
Edsger W. Dijkstra. The humble programmer. Commun. ACM 15
(1972), 1972.
[Ent07]
Enterprice Architect, 2007. http://www.sparxsystems.com.au/.
[EPC07]
EPK-Community Website, 2007. http://www.wiso.uni-hamburg.
de/index.php?id=1604\&L=0.
[Fuj07a]
Fujaba life website, 2007. http://wwwcs.uni-paderborn.de/cs/
fujaba/projects/education/index.html.
[Fuj07b]
Fujaba real-time tool suite website, 2007.
http://wwwcs.
uni-paderborn.de/cs/fujaba/projects/realtime/index.html.
[Fuj07c]
Fujaba tgg website, 2007. http://wwwcs.uni-paderborn.de/cs/
fujaba/projects/tgg/index.html.
[Fuj07d]
Fujaba tool suite reengineering website, 2007. http://wwwcs.
uni-paderborn.de/cs/fujaba/projects/reengineering/index.
html.
[Fuj07e]
Fujaba Website, 2007.
fujaba/.
[Fuj07f]
Fujaba4eclipse website, 2007. http://wwwcs.uni-paderborn.de/
cs/fujaba/projects/eclipse/index.html.
http://wwwcs.uni-paderborn.de/cs/
Bibliography
118
[GGL05]
Lars Grunske, Leif Geiger, and Michael Lawley. A graphical specification of model transformations with triple graph grammars. University
of Queensland, 2005.
[IBM07]
Rational Software Architect 7.0, 2007. http://www.ibm.com/.
[ide93]
Integration definition for information modeling (idef1x), 1993.
http://www.itl.nist.gov/fipspubs/idef1x.doc.
[ISI07]
Isilet Website, 2007.
http://wwwcs.uni-paderborn.de/
fachbereich/AG/schaefer/ag_dt/ISILEIT/index.html.
[KL06]
Birtgit Korherr and Beate List. A uml 2 profile for event driven
process chains. Vienna University of Technology, 2006.
[Kön05]
Alexander Königs. Model transformation with triple graph grammars.
University of Technology Darmstadt, 2005.
[KNS92]
G. Keller, M. Nüttgens, and A. W. Scheer. Semantische Prozessmodellierung auf der Grundlage Ereignisgesteuerten Prozessketten (EPK),
1992.
[Kor05]
Birgit Korherr. UML-Profil für Geschäftsprozesse. Master’s thesis,
Vienna University of Technology, 2005.
[Mag07]
Magic Draw UML 15.0, 2007. http://www.nomagic.com/.
[MCG05]
Tom Mens, Krzysztof Czarnecki, and Pieter Van Gorp. A taxonomy
of model transformations. Dagstuhl Seminar Proceedings 04101, 2005.
[MDA07]
MDA Website, 2007. http://www.omg.org/mda/.
[MK06]
Marion Murzek and Gerhard Kramler. Business process model transformation issues. Vienna University of Technology, 2006.
[MKM06] Marion Murzek, Gerhard Kramler, and Elke Michlmayr. Structural
patterns for the transformation of business process models. Vienna
University of Technology, 2006.
[MSU04]
S. Mellor, K. Scott, and A. Uhl. MDA Distilled. Addison-Wesley
Verlag, 2004.
[Obj07]
Object Management Group. OMG Website, 2007. http://www.omg.
org.
[OMG07a] UML 2.1.1 Infrastructure Specification, 2007. http://www.omg.org/
docs/formal/07-02-04.pdf.
[OMG07b] UML 2.1.1 superstructure specification, 2007. http://www.omg.org/
docs/formal/07-02-03.pdf.
[Oul95]
M. Ould. Business Processes: Modelling and Analysis for Reengineering and Improvement. Wiley, 1995.
Bibliography
119
[Pra71]
T.W. Pratt. Pair grammars, graph languages and string-to-graph
translations. Journal of Computer and System Sciences 5 560 595,
1971.
[RM06]
Jan Recker and Jan Mendling. On the translation between bpmn
and bpel: Conceptual mismatch between process modeling languages.
Proceedings 18th International Conference on Advanced Information
Systems Engineering. Proceedings of Workshops and Doctoral Consortiums, pages 521–532, 2006.
[SAP07]
SAP R/4, 1992-2007. http://www.sap.com/.
[Sch91]
August-Wilhelm Scheer. Architektur integrierter Informationssysteme. Springer-Verlag, 1991.
[Sch95]
Andy Schürr. Specification of graph translators with triple graph
grammars. University of Aachen, 1995.
[Stö06]
Harald Störrle. A comparison of (e)epcs and uml 2 activity diagrams.
In EPK 2006: Geschäftsprozessmanagement mit Ereignisgesteuerten
Prozessketten 5. Workshop der Gesellschaft für Informatik e.V., pages
177–188, 2006.
[TEG+ 05] Gabriele Taentzer, Karsten Ehrig, Esther Guerra, Juan de Lara, Laszlo Lengyel, Tihamer Levendovszky, Ulrike Prange, Daniel Varro, and
Szilvia Varro-Gyapay. Model transformation by graph transformation: A comparative study. Technische Universität Berlin and Universidad Carlos III de Madrid and Universidad Autonoma de Madrid
and Budapest University of Technology and Economics, 2005.
[Tel06]
Telelogic TAU 3.1, 2006. http://www.telelogic.com/.
[Vis]
Ms Office Visio. http://www.microsoft.com/austria.
[Vis07]
Visual Paradigm for UML, 2007. http://www.visual-paradigm.
com/.
[Wen05]
Lothar Wendehals. 10 steps to build a fujaba plugin, 2005. http://
www.se.eecs.uni\discretionary{-}{}{}kassel.de/fujabawiki/
images/2/2c/10_Steps_To%_Build_a_Fujaba_Plugin.pdf.

paper - Business Informatics Group

Transcription

Similar documents

TP Brochure final final

Mahsa - Department of Computer Science

chimb.ca

Life as a Grammarist

Becoming a Missional Church in Transformation

Software Documentation Overview

Smart Node Pod - Northrop Grumman

Transformation to World Leading Quality: Is Your

Record of Achievement