on the usability of triple graph grammars for the ... · uml 2.x’in olaya- dayal sure˘ c...

TU Wien

Business Informatics GroupInstitut für Softwaretechnik und Interaktive Systeme

Güzide Selin Altan

On the Usability of Triple Graph Grammarsfor the Transformation of Business ProcessModels - An Evaluation based on FUJABA

Magisterarbeit zur Erlangung des akademischen Gradeseines Magister der Sozial- und Wirtschaftswissenschaften

eingereicht bei o. Univ.-Prof. Mag. Dipl.-Ing. Dr. Gerti Kappelmitbetreuende Assistentin Mag. Marion Murzek

Wien, January 15, 2008

1

Abstract

In recent years the need for business process model transformation hasincreased. The primary reason for this is the importance of business to businessinteroperability. A lot of research is done in this area. Several transformationtechniques exist in the field of MDA which is the model driven architecture asdefined by Object Management Group (OMG).

In Business Process Modeling many modeling languages such as BusinessProcess Modeling Notation, UML 2.1 Activity Diagrams, Event-Driven ProcessChains et cetera are used. There is also a certain diversity in transformation tech-niques such as ATL, QVT or Kermeta. Most model transformation approachesfocus on software development, and less in business processes. Therefore someapproaches may be more or less suitable for this task than others.

In this master thesis, a transformation approach, namely Triple GraphGrammars will be inspected for its suitability in business process model trans-formation. Event-driven Process Chains and Activity Diagrams from UML 2.xare chosen as business process modeling languages because of the wide spreadpopularity of these languages. Fujaba will be used as transformation tool for itsTriple Graph Grammar support and its extendibility.

In the thesis the business process modeling languages Event-driven ProcessChains and Activity Diagrams are described. Furthermore, several examplemodels for Event-driven Process Chains and Activity Diagrams are defined. Inthe practical part the goal is to develop Fujaba plug-ins for those modelinglanguages, as well as to define the Triple Graph Grammars rules based on thenew plug-ins. The example models will be needed to test if the Triple GraphGrammar rules are intend correctly.

Fujaba is an open source project from the University of Paderborn. Its primarytopic is to provide an extendable platform for UML, Story Driven Modeling andGraph Transformation platform with the ability to add plug-ins. In the masterthesis this tool is used because of its mature Triple Graph Grammar supportAnother reason is its extensibility which is useful for creating custom plug-insfor Event-driven Process Chains and Activity Diagrams.

The plug-ins are developed with Java and rely on the meta models of ActivityDiagrams and Event-driven Process Chains. The prepared meta models are alsoused when defining the Triple Graph Grammar rules as initial point. The metamodels and the transformation are focused on Control Flow of business processes,because of its central importance in business process modeling. Organizationalflow 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 modeltransformation with triple graph grammars will be evaluated.

3

Kurzfassung

In den letzten Jahren ist der Bedarf an Modelltransformation im Bereich vonGeschäftsprozessmodellierung angestiegen. Der Hauptgrund dafür ist die Bedeu-tung von Business-to-Business Interoperabilität. In diesem Bereich wird auchsehr viel geforscht. Im Bereich von MDA, wie er von der Object ManagementGroup definiert wurde, existieren bereits einige Transformationstechniken.

In der Modellierung von Geschäftsprozessen werden viele Model-lierungssprachen, wie etwa Business Process Modeling Notation, UML 2.1Activity Diagram oder Event-driven Process Chains und so weiter verwendet.Auch bei Transformationssprachen gibt es eine gewisse Vielfalt, wie zum BeispielATL, QVT, oder Kermeta. Die meisten Modelltransformationsansätze legen denFokus auf Softwareentwicklung, und weniger auf Geschäftsprozesse. Aus diesemGrund können sich verschiedene Ansätze mehr oder weniger für diese Aufgabeeignen als andere.

In dieser Masterarbeit wird ein Transformationsansatz, nämlich Triple GraphGrammars, auf seine Eignung für Modelltransformation von Geschäftsprozessenhin untersucht. Ereignisgesteuerte Prozessketten und UML 2 Aktivitätsdiagramewerden dafür als Geschäftsprozesssprache ausgewählt, da sie sehr verbreitetsind. Fujaba wird als Transformationswerkzeug eingesetzt, da es Triple GraphGrammars unterstützt und erweiterbar ist.

In dieser Arbeit werden die Geschäftsprozessmodellierungssprachen Ereignis-gesteuerte Prozessketten und Aktivitätsdiagrame beschrieben. Weiters werdenmehrere Beispiele für diese Sprachen definiert. Im praktischen Teil ist das Ziel,Fujaba-Plugins für die Modellierungssprachen und darauf basierend Triple GraphGrammar Regeln zu erstellen. Die Beispielmodelle werden verwendet, um dieKorrektheit der Triple Graph Grammar Regeln zu testen.

Fujaba ist ein Open-Source Projekt von der Universität Paderborn. SeinHauptziel ist es, eine erweiterbare Plattform für UML, Story Driven Modelingund Graphtransformation mit Erweiterbarkeit durch Plug-ins zur Verfügungzu stellen. In dieser Arbeit wird dieses Tool aufgrund seiner fortgeschrittenenTriple Graph Grammar Unterstützung verwendet. Ein weiterer Grund ist dieErweiterbarkeit. Dadurch ist es möglich, eigene Plug-ins für EreignisgesteuerteProzessketten und Aktivitätsdiagrame zu erstellen.

Die Plug-ins sind in Java entwickelt und basieren auf den Metamodellen derEreignisgesteuerte Prozessketten und Aktivitätsdiagrame. Diese Metamodellewerden auch beim Definieren der Triple Graph Grammar Regeln verwendet. DieMetamodelle und die Transformation konzentrieren sich auf den Kontrollflussvon Geschäftsprozessen, weil diese Sicht von zentraler Wichtigkeit dafür ist. DieOrganisationssicht wird zusätzlich auch betrachtet.

4

Um eine Aussage zu treffen, wie geeignet der beschriebene Ansatz ist, wird einKriterienkatalog definiert. Basierend auf diesen Kriterien wird die Transforma-tion 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̧aartmıştır. Bunun temel nedeni işten-işe birlikte işlerliğindeki önemdir. Bu konuile ilgili çok fazla araştırma yapılmaktadır. OMG Grubu (Object ManagementGroup) tarafından tanımlanmış model sürücülü mimari olan MDA (ModelDriven Architecture) alanında pek çok transformasyon mevcuttur.

Yönetsel Süreç Modellemesinde, Business Process Modeling Notation, UML2.1 Activity Diagrams, Event-driven Process Chains gibi birçok modelleme dilikullanılmaktadır. ATL, QVT veya Kermeta gibi dönüşüdm tekniklerinde debirtakım çeşitlemeler bulunmaktadır. Pek çok model dönüşüm yaklaşımlarındayazılım geliştirmeye yönetsel süreçlerden çok daha fazla odaklanılmaktadır. Bunedenle de yönetsel süreç modellemede bazı yaklaşımlar diğerlerine göre dahafazla veya daha az uygun olabilir.

Bu yüksek lisans tezinde, yönetsel süreç modeli dönüşümüne uygunluğunedeni ile üçlü- çizge dilbilgisi (Triple Graph Grammars) olarak adlandırılan birdönüşüm yaklaşımı incelenmektedir. UML 2.x’in olaya- dayalı süreç zincirleri veactivite diyagramları, bu dillerin yaygın biçimde kullanımları nedeni ile, yönetselsüreç modelleme dili olarak seçilmiştir. Fujaba ise, üçlü - çizge dilbilgisini destek-lemesi 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̧ zincirlerive aktivite diyagramları açıklanmıştır. Ayrıca olaya- dayalı süreç zincirlerive aktivite diyagramlarına da birkaç örnek verilmiştir. Uygulama bölümününamacı modelleme dilleri için uyumlu ekler geliştirmek ve ayrıca üçlü- çizgedilbilgisi 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 edilmelerigerekecektir

Fujaba Paderborn Üniversite’sinde geliştirilmiş bir açık kaynak proje-sidir. Öncelikli konuları UML için, SDM (Story Driven Modeling) ve çizgedönüşümü platformunun uyumlu ekler ile genişletilebilir birer platform ol-maları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̈zeregenişletilebilmesidir.

Uyumlu ekler Java dilinde yazılmıştır ve bunlar aktivite diyagramları ile olaya-dayalı süreç zincirlerinin meta modellerine dayanmaktadır. Hazırlanan metamodeller 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 birkriterler listesi tanımlanmıştır. Üçlü çizge dilbilgisi ile yönetsel süreç modellemebu kriterlere göre değerlendirilmektedir.

7

Eidesstattliche Erklärung

Ich erkläre an Eides statt, daß ich die vorliegende Arbeit selbständig und ohnefremde Hilfe verfasst, andere als die angegebenen Quellen nicht benützt und dieden benutzten Quellen wörtlich oder inhaltlich entnommenen Stellen als solchekenntlich 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 theend 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 withtransformations in Fujaba.

Last but not least, Marion Murzek and Gerti Kappel who supervised andguided me along the preparation process of this thesis.

9

Contents

I. Introduction 12

1. Introduction 131.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.2. Model Driven Engineering . . . . . . . . . . . . . . . . . . . . . . 131.3. Business Process Modeling . . . . . . . . . . . . . . . . . . . . . . 151.4. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.5. Structure of the Master Thesis . . . . . . . . . . . . . . . . . . . . 17

II. Business Process Modeling Languages 18

2. Event-driven Process Chains 192.1. History of Event-driven Process Chains . . . . . . . . . . . . . . . 192.2. General Description of Event-driven Process Chains . . . . . . . . 192.3. Meta Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.3.1. Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.3.2. Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.3.3. Logical Operator . . . . . . . . . . . . . . . . . . . . . . . 23

The Logical Operator “AND“ . . . . . . . . . . . . . . . . 23The Logical Operator “OR“ . . . . . . . . . . . . . . . . . 24The Logical Operator “XOR“ . . . . . . . . . . . . . . . . 25

2.3.4. Organizational Unit . . . . . . . . . . . . . . . . . . . . . . 262.3.5. Flow Connector . . . . . . . . . . . . . . . . . . . . . . . . 27

Control Flow Connector . . . . . . . . . . . . . . . . . . . 27Organizational Flow Connector . . . . . . . . . . . . . . . 27

2.4. Example Models . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3. UML Activity Diagrams 323.1. Object Management Group (OMG) . . . . . . . . . . . . . . . . . 32

3.1.1. History of UML . . . . . . . . . . . . . . . . . . . . . . . . 323.1.2. General Description of UML . . . . . . . . . . . . . . . . . 33

3.2. General Description of Activity Diagrams . . . . . . . . . . . . . . 343.3. Meta model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.3.1. Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.3.2. Activity Node . . . . . . . . . . . . . . . . . . . . . . . . . 373.3.3. Action Node . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37CallBehavior Action . . . . . . . . . . . . . . . . . . . . . 37

Contents 10

3.4. Control Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Initial Node . . . . . . . . . . . . . . . . . . . . . . . . . . 38Final Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 38Decision Node . . . . . . . . . . . . . . . . . . . . . . . . . 39Merge Node . . . . . . . . . . . . . . . . . . . . . . . . . . 39Fork Node . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Join Node . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.4.1. Activity Edge . . . . . . . . . . . . . . . . . . . . . . . . . 413.4.2. Activity Partition . . . . . . . . . . . . . . . . . . . . . . . 42

3.5. Example Models . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

III. Transformation with Fujaba 47

4. Problem description 484.1. Conceptual Element-to-Element Mapping . . . . . . . . . . . . . . 484.2. Mapping Variants . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5. Triple Graph Grammars 595.1. Pair Graph Grammars versus Triple Graph Grammars . . . . . . 595.2. Triple Graph Grammars Rules . . . . . . . . . . . . . . . . . . . . 605.3. TGG Rule Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . 62

6. Developing Fujaba Plug-ins 646.1. Fujaba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 646.2. Required Software for Triple Graph Grammars . . . . . . . . . . . 666.3. Steps to build the Event-driven Process Chain and Activity Dia-

gram Plug-ins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 666.3.1. Implementing the Plug-in Interface . . . . . . . . . . . . . 666.3.2. Defining the Meta Models . . . . . . . . . . . . . . . . . . 676.3.3. Connecting to Fujaba´s Meta Model . . . . . . . . . . . . 676.3.4. Implementing the Actions . . . . . . . . . . . . . . . . . . 686.3.5. Defining Concrete Syntax . . . . . . . . . . . . . . . . . . 696.3.6. User Interface . . . . . . . . . . . . . . . . . . . . . . . . . 716.3.7. Implementing the Frame Decorator . . . . . . . . . . . . . 726.3.8. Defining the Plug-in Description . . . . . . . . . . . . . . . 736.3.9. Deploying the Plug-in . . . . . . . . . . . . . . . . . . . . 736.3.10. What Features Are Supported in Both Plug-ins? . . . . . . 73

6.4. Problems Faced When Using Fujaba . . . . . . . . . . . . . . . . 746.4.1. Example Models in Fujaba . . . . . . . . . . . . . . . . . . 75

7. Defining TGG Rules for Model Transformation 787.1. Model Transformation Project . . . . . . . . . . . . . . . . . . . . 79

7.1.1. Correspondence Meta Model . . . . . . . . . . . . . . . . . 797.1.2. MoTE Meta Model . . . . . . . . . . . . . . . . . . . . . . 817.1.3. MoTE Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 827.1.4. Event-Driven Process Chain and Activity Diagram Meta

Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Contents 11

7.2. Defining Triple Graph Grammar Rules with Fujaba´s TGG Editor 857.2.1. Mapping of Fork/Join and Decision/Merge Nodes . . . . . 98

7.3. Java Project with Triple Graph Grammar Rules . . . . . . . . . . 987.4. Lessons learned . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

8. Evaluation of Triple Graph Grammars with Fujaba 1028.1. Criteria Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

8.1.1. Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 1038.1.2. Rule Organization . . . . . . . . . . . . . . . . . . . . . . 1038.1.3. Rule Application Control . . . . . . . . . . . . . . . . . . . 1048.1.4. Application Conditions . . . . . . . . . . . . . . . . . . . . 1048.1.5. Syntactic Separation . . . . . . . . . . . . . . . . . . . . . 1048.1.6. Traceability Support . . . . . . . . . . . . . . . . . . . . . 1048.1.7. Incrementality . . . . . . . . . . . . . . . . . . . . . . . . . 1058.1.8. Directionality . . . . . . . . . . . . . . . . . . . . . . . . . 1058.1.9. Consistency Checking . . . . . . . . . . . . . . . . . . . . . 1058.1.10. Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . 1068.1.11. Usability . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

8.2. Lessons learned . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

9. Conclusion 1099.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1099.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 integrationwhen companies merge, model translation for business to business interoperabil-ity and model synchronization within a company are some of the reasons forthe need of business process model transformations (see Figure 1.1). In modelintegration, models conforming to different business process modeling languagesare integrated to create a new model, which conforms to another business processmodeling language. In model translation, models conforming to one businessprocess modeling language are transformed to models conforming to anotherlanguage. In model synchronization pairs of models are synchronized after userchanges [MKM06].

Figure 1.1.: Different Model Transformation Scenarios, taken from [MKM06]

Most of the work done about model transformation is in the field of softwaremodeling. In comparison to that, little work has been done to integrate modeltransformation into the business process modeling area. In this master thesis thequestion is, if model transformation with Triple Graph Grammars may also beapplied in the area of business process modeling.

The aim of the work is to translate models of two different business processmodeling languages into each other with the transformation approach TripleGraph 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. Inthis, models are considered the central artefact of software development. Model

1. Introduction 14

Driven Architecture (MDA) is a well-known MDE initiative, developed by theOMG [MDA07]. MDA aims to replace code as the central artefact generated bya software engineering process with models.

Software development has risen in complexity ever since it exists. Thesoftware crisis in the 1960s and 1970s is an early example, which illustrates thisissue [Dij72]. More processing power makes it possible to write more complexprograms. However, without appropriate development tools and programminglanguages, it becomes hard to manage this complexity. During the softwarecrisis, this resulted in generally low-quality programs, which were created inover-time and over-budget development projects.

With the rising complexity and size of the software developed, the program-ming languages used, also evolved [MSU04]. Assembler languages, as used in theearly days of software development, are machine-oriented and reside thereforeat a very low abstraction layer. Later, languages appeared, which provide asomewhat higher abstraction layer. A notable example for these languagesis C, which is not as machine-bound as assembler languages. In the 1980s,object-oriented languages gained acceptance. These languages reside at an evenhigher abstraction level, and provide techniques for structuring complex code, sothat it can be maintained more easily by the developers.

In the 2000s, languages like Java, C#, or Ruby are very popular because oftheir high abstraction. As next logical step, MDA proposes not to use a specificprogramming language for implementing software [MSU04]. The software shouldbe modeled using a modeling language like UML. Later on, code for a specificplatform is generated from the software model. This is achieved using platform-independent models and transforming them into platform-specific models byadding platform specific information.

Because code in a specific programming language may also be seen as a modelconforming to a meta model, code generation may also be viewed as modeltransformation. For this reason, model transformation is a key technology inmodel driven engineering and model driven architecture in particular. From amore general point of view, model transformation is used to transform one ormore source models into one or more target models.

Nowadays, many model transformations approaches exist. In this thesis TripleGraph Grammars are used, which are a graph based and declarative approach.They have been introduced in the early nineties by Andy Schürr [Sch95]. TripleGraph Grammar rules may be implemented using the tool Fujaba [Fuj07e]. Itis developed at the university of Paderborn and consists of several subprojects.One of its projects support the use of Triple Graph Grammars. Moreover it hasan 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 toDavenport [Dav93] a business process is:

A structured, measured set of activities designed to produce a specificoutput for a particular customer or market. It implies a strong em-phasis on how work is done within an organization, in contrast to aproduct focus‘s emphasis on what. A process is thus a specific order-ing of work activities across time and space, with a beginning and anend, and clearly defined inputs and outputs: a structure for action...Taking a process approach implies adopting the customer‘s point ofview. Processes are the structure by which an organization does whatis necessary to produce value for its customers.

Several reasons exist for modeling business processes [Oul95]:

• Document the processes: Documenting the business processes is helpful todeal with costumer requirements. Another reason to document the businessprocesses is for internal communication within a company.

• Analyze the processes: By analyzing the business processes their qualitymay be improved. Potential problems or bottlenecks may be identified.

• Simulate the execution of the processes. In this case, process models areexecuted using sample data, therefore it is possible to identify problems,which cannot be found by statical analysis. This may be achieved usingworkflow engines, or environments especially designed for business processexecution, for example, Business Process Execution Language [bpe07].

There are many business process modeling languages like UML ActivityDiagram, BPMN (Business Process Modeling Notation [bpm06]), Event- DrivenProcess Chains [KNS92], IDEF (Icon Definition Language [ide93]) etc. For thetransformations in this master thesis UML 2.1 Activity Diagram and Event-Driven Process Chains have been chosen because of their widespread usage andacceptance.

Business process modeling languages contain different aspects, namely controlflow, organizational flow and informational aspects. This work concentrateson the control flow and the organizational flow aspect. They are described indetailed in the next sections.

In Figure 1.2, the focus of this thesis is illustrated. Model Transformation andBusiness Process Modeling belong to the area Model Driven Engineering. Thisthesis integrates and combines concepts of both subfields, and is therefore itselfa 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 modeltransformation, see Figure 1.2. Especially model transformation is a current fieldof research. There have also been other works, which deal with the integration ofbusiness process languages and model transformation. For example, in [MK06]Marion Murzek and Gerhard Kramler concentrated on different business processlanguages and the problems concerning their transformation. They focused onthe control flow of the respective languages. Several issues are presented, whichfrequently occur when transforming business process languages into each other.Some of the issues found are also present in this thesis. Their respective solutionsare illustrated in ATL.

In [MKM06], Murzek et. al. present a pattern-based approach to thetransformation of business processes. Several patterns are presented, whichlie on a higher abstraction level than meta model elements generally used inmodel transformation languages like ATL. As an example, the transformation ofADONIS models into Event-driven Process Chains is shown. The latter is alsoused in this thesis. The transformation scenarios in this thesis are similar to thepatterns as described by Murzek et. al.

Birgit Korherr and Beate List describe an UML profile for Event-drivenProcess Chains in [KL06]. This profile may be used for modeling Event-drivenProcess Chains using UML Activity Diagrams. Although no transformationbetween the two languages is defined, a mapping of their concepts is introduced.

In [Stö06], Harald Störrle compares Event-driven Process Chains and UMLActivity Diagrams from a syntactic and semantic view. Also, the concerningrelated 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 pre-sented in [TEG+05] by Gabriele Taentzer et. al. The four languages comparedand evaluated are AGG, AToM3, VIATRA2 and VMTS. Triple Graph Grammarswith Fujaba are not included, the focus lies on other graph based transformationlanguages.

In [RM06], Jan Recker and Jan Mendling describe the transformation betweenBPMN to BPEL. Mismatches and problems of this transformation are discussedand analyzed. They concentrate on a more theoretical point of view and do notprovide an implementation for the transformation.

1.5. Structure of the Master Thesis

Section 1 gives an introduction to MDE and business process modeling. More-over, the motivation and aim of this master thesis is explained.

In Sections 2 and 3 the chosen business process modeling languages namelyEvent-driven Process Chains and Activity Diagrams are introduced. Their metamodels and elements considering the syntax and notation are explained in detail.Furthermore, example models are defined and modeled to illustrate how thetransformation will work.

In Section 4 the transformation scenarios are documented and modeled withoutconsidering a specific model transformation approach. Thus, the problems areidentified and possible solutions are proposed.

In Section 5 a short introduction to Triple Graph Grammars is given. Itsfeatures and functionality is explained.

In Section 6 the transformation tool Fujaba is introduced. It has been chosenas transformation tool because of its Triple Graph Grammar support. Aspreparatory work for model transformation, Event-driven Process Chain andActivity Diagram plug-ins are written in Java and integrated to Fujaba´s library.

In Section 7 the Triple Graph Grammar rules for the transformation ofEvent-driven Process Chains to Activity Diagrams with Fujaba are defined. Theproblems and the solutions are illustrated.

Section 8 is about evaluating Triple Graph Grammars with Fujaba. Mostof the chosen criteria are based on the paper “Feature-based survey of modeltransformation approaches“ by K. Czarnecki [CH06].

In the last section, a conclusion of this master thesis is provided.

18

Part II.

Business Process ModelingLanguages

19

2. Event-driven Process Chains

In this section, the basic concepts of Event-driven Process Chains are explained.Further, the history, general description and meta model is described and theelements 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) hasbeen introduced in 1992 by Sheer, Keller and Nüttgens [KNS92].

Origins of the Event-driven Process Chains base on CIM (Computer IntegratedManufacturing) which has been developed in 1980s by CASA/SME (Computerand Automated Systems Association / Society for Manufacturing Engineers). InCIM the whole manufacturing process is integrated. It contains both softwaremodeling and management concept, so it has a rather complex superstructure.Furthermore, it has no special framework to realize modeling the businessprocesses within a company [Sch91].

In 2002, Prof. Markus Nüttgens and Prof. Frank Rump launched a communitynamed “Business Process Management with Event-Driven Process Chains“ at theuniversity of Hamburg. This community organizes workshops, does research andpublishes journals about business process management. Their major topics aresyntax, semantic, modeling concepts and application concepts of Event-drivenProcess Chains. On the community‘s homepage numerous journals about itstopics can be found [EPC07].

2.2. General Description of Event-driven ProcessChains

Event-driven Process Chains are based on concepts of ARIS [Ari]. The archi-tecture of ARIS consists of three aspects; data, function and organizational(behavior) aspects. The data aspect contains environmental infrastructure anddata which is used by functions during the process. The function aspect describesthe control flow of the process. Organizational aspect consists of persons, rolesor departments which are involved during the process [Sch91]. Other toolswhere Event-driven Process Chains are interpreted are SAP R/3 [SAP07], ARIS,ADONIS [Boc05], and Visio [Vis].

2. Event-driven Process Chains 20

This work concentrates on the function (behavior) aspect also known ascontrol flow aspect and organizational aspect of Event-driven Process Chains.The control flow aspect is the main aspect of the business process modelinglanguages. The organizational aspect has been chosen as the second aspect fortest and comparison purposes.

2.3. Meta Model

In this section the meta model of the Event-driven Process Chains (see Figure2.1) will be described. It contains the control flow and the organizational aspectsof the Event-driven Process Chains.

The control flow aspect contains the elements Event, Function, LogicalOperators and Control Flow. The elements of the organizational view are theOrganizational Unit and Organizational Flow.

An Event-driven Process Chain consists of Process Objects, OrganizationalUnits and Flow Connectors. Process Objects and Organizational Units are nodesin the Event-driven Process Chains. Process Objects may either be Functions,Events or Logical Operators. Flow Connectors are edges of Event-driven ProcessChains. 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 ProcessChain, because there is no dedicated start or end element. It starts with one ormore Events and ends with one or more Events. An Event may have at mosttwo Control Flows: One incoming and one outgoing flow. The first Event in theEvent-driven Process Chains has no incoming Control Flow and the last Eventhas 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 andone outgoing Control Flow. A Function may be a Basic Function or a ComplexFunction. The Logical Operators may have multiple incoming and outgoingControl Flows. There are three Logical Operators in the Event-driven ProcessChains, “AND“, “OR“, and “XOR“. Organizational Units are connected withFunctions via the Organizational Flow. An Organizational Unit has at leastone Organizational Flow. Events and Functions have to alternate, but it is notpossible to illustrate this constraint in the meta model.

Process Object, Flow Connector und EPCDiagram are abstract classes of theEvent-driven Process Chain meta model and are not used directly in diagrams,however their subclasses are. In the following each element will be describedconsidering its syntax and notation.


Figure 2.1.: Event-driven Process Chain meta model


2.3.1. Function

The class Function in the meta model is an abstract class and may either be aBasic Function or a Complex Function.

Basic Function

A Basic Function is a task which describes an Activity or a task that has tobe executed by a Organizational Unit in a certain period of time. They lead toEvents [Kor05]. Basic Functions are atomic, they cannot be further divided. ABasic Function cannot call another Basic Function. Basic Functions and Eventshave to alternate. The Basic Function is depicted by a rounded rectangle (seeFigure 2.2).

Figure 2.2.: Notation: Basic Function

Complex Function

The Complex Functions is used to model a sub-process call. A Complex Func-tion has to be refined in another Event-driven Process Chain. The notation ofComplex Functions is a rectangle with rounded corners with a little Event-drivenProcess 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 aFunction is executed. After an Event has occurred a Function can be executed.


Figure 2.4.: Notation: Event

Events trigger Functions. In an Event-driven Process Chain, it is not allowedcalling an Event immediately after another Event.

Event-driven Process Chains start and end with Events. They do not have aspecial element like the Initial Node and Final Node of Activity Diagrams whichmarks the beginning and end of the diagram. The notation of an Event is ahexagon (see Figure 2.4).

2.3.3. Logical Operator

Logical Operators are used to connect Events and Functions by decisions orparallel executions . There are three types of Logical Operators: “AND“, “OR“,“XOR“.

Each of the three Logical Operators is used to split the flow into multipleflows. 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 oftrue by two or more operands if all operands are true. In Event-driven ProcessChains, “AND“ splits the execution path (Control Flow). After that two ormore 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 besplit and have to be joined after the execution (see Figure 2.6).


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 operandsif one or more of its operands are true. “OR“ is called “logical disjunction“ inmathematics (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 aFunction may trigger a logical disjunction.


Figure 2.9.: The logical operator “OR“ splits

After each subflow is executed they have to be joined with “OR“ again. Thenthe 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 moreoperands 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 ormore flows. Only one flow may be executed alternatively. Parallel execution ofpaths is not allowed. As seen in the Figure 2.12 only a Function may trigger anexclusive disjunction.


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 byOrganizational Units. Persons, departments and roles are illustrated withOrganizational Units. They are responsible for executing Functions. They areconnected 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 insideand is shown in Figure 2.14.


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 OrganizationalFlow Connector.

Control Flow Connector

Functions, Events and Logical Operators are connected via Control Flow. Thenotation of a Control Flow is an arrow and is depicted in Figure 2.15. Its arrowhead 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. AFunction may be assigned to multiple Organizational Units with OrganizationalFlows.

Figure 2.16.: Notation: Organizational Flow Connector

The notation of the Organizational Flow Connector is a simple line (see Figure2.16). Because no execution order exists in the organizational view, no arrow isused as organizational flow connector.

2.4. Example Models

As example scenario a home care providing company and three of its processesare 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 independentlyand the company supports their household and some medical treatments whichare prescribed from the doctor.

In the first model the process ”Patient orders Home Care” is described. Assoon as the order information is checked, the home care providing companyemployee (HCPC Employee) makes an appointment for an interview with thepatient. It is also recommended that at least one relative of the patient attends


this interview as well.

During the interview, the care plan for the patient is discussed. If the patientneeds a medical plan, it will be planed by a doctor. The non-medical carecontains jobs to be done in the household, like cooking, washing. This does nothave to be done by nurses or licensed medical personnel. The medical care canonly be provided by nurses, doctors, or other licensed medical personnel. All ofthe care takers (HCPC Care Taker) are personnel from the home care providingcompany.

Afterwards, the patient is assigned to a hospital to appoint his or her careneed grade. According to this grade the costs for home care are compensated bythe state or the patient has to pay him or herself. If the care need grade is highthe home care providing company has to contact the state because the costs willbe compensated by the state.

If the patient has to pay for home care costs, a cost plan will be discussed withthe HCPC Employee. Finally, the medical plan and the payment methods bothfrom the company and the patient side are confirmed. So the process ”HomeCare Order” is finished. (see Figure 2.17)

The second process is the ”Home Care” process as seen in Figure 2.18. Duringthe days when home care is planned, personnel from care taker departmentprepare the service car and equipment needed. After that, they are ready todrive to their patients.

When a care taker (HCPC Care Taker) arrives at the patient´s home, andnobody opens the door, he or she has to contact and inform the patient´srelatives. When the patient is at home, the home activities will be done anddocumented. The documented home care activities have to be sent to thecompany after each home care via PDA.

The third process (Figure 2.19) shows the home care activities in detail. Whena care taker arrives at the patient, he or she goes through the patients home careplan. Depending on the care plan, medical care, non-medical care or both of itare done.

Activities like washing the patient, changing his clothes, washing dishes,washing clothes, ironing, cooking, cleaning, tidying up do not belong to medicalcare. Measuring the pulse, giving pills, injections, serums are tasks of the medicalcare.

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


Figure 2.18.: Example Model 2: Home Care


Figure 2.19.: Example Model 3: Home Care Activities

32

3. UML Activity Diagrams

This section gives a short overview of Object Management Group, UML in gen-eral, and UML Activity Diagrams.

3.1. Object Management Group (OMG)

The OMG is an international non-profit computer industry consortium foundedin 1989. OMG sets enterprise integration standards for many technologies. UMLis its most used standard. It has hundreds of members, among them universitiesor big and small software companies such as IBM, Oracle, Microsoft, SunMicrosystems, Hewlett-Packard, Software AG, DaimlerChrysler, Intel, Siemensetc.

The OMG covers a wide range of topics in the field of integration standards.Real-time, Embedded and Specialized Systems, Analysis & Design, Architecture-Driven 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 havemany advantages, they can join technical meetings, conferences and other eventsof 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), CommonObject Request Broker Architecture (CORBA), XML Metadata Interchange(XMI) and Business Process Modeling Notation (BPMN)and Systems ModelingLanguage (SYsML).

3.1.1. History of UML

The roots of object-oriented modeling languages reach to the 70s and 80s of theprevious century. There have been a few developers experimenting in the area ofobject-oriented analysis and design. The “Entity Relationship Model“ (ERM)and the “Specification and Description Language“ (SDL) influenced first objectoriented modeling languages [Kor05].

In 1994 there were about 50 different object oriented modeling languages. Atthat 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

3. UML Activity Diagrams 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 Rumbaughfrom General Electric Research and Development Center began to work together.Rumbaugh joined the Rational Software Company. They merged the Methodsof Booch and OMT and released their concept named “Unified Method“ inOctober 1995. After Jacobson has been joined Booch and Rumbaugh, “OOSE“integrated to Unified Method, as well. The new method was called “RationalUnified Method“. In June 1996 UML 0.9 was published by these three develop-ers. They got positive feedback and had motivation to go on working. In 1996,the OMG requested for a proposal of a modeling standard. Booch, Rumbaughand Jacobson reacted and proposed UML 1.0. UML has been adopted to OMGas modeling standard since November 1997 [Kor05].

Until that time, UML had only three developers: Booch, Rumbaugh andJacobson. After UML has been accepted by OMG, the number of its developersgrew, so that UML 1.1 could be released soon (1997) [OMG07b].

Since then several UML revisions have been released. Each of them had moreFunctionality and refinements. New diagrams and features have been added,and problems and lacks have been addressed and corrected. The current officialversion 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 ofapplication domains. [OMG07a, page 1]

UML may be used in various kinds of projects and in different ways. UMLis used to design software, to model business processes, to show parts of asystem or its activities, to show communication between systems, to explain thefunctionality of a system etc.

UML currently consists of thirteen diagrams. These are divided into “StructureDiagrams“ and “Behavior Diagrams“. Structure diagrams show the internalstructure of a system independent of time. Class Diagrams, ComponentDiagrams, Composite Structure Diagrams, Deployment Diagrams, PackageDiagrams and Object Diagrams belong to structure diagrams of UML. Behaviordiagrams concentrate on the dynamic constructs in a system. They havedynamic character and show the changes in diagrams depending on time. Thereare eight behavior diagrams in UML: Activity Diagrams, Use Case Diagrams,State Machine Diagrams, Interaction Diagrams, Sequence Diagrams, InteractionOverview Diagrams, Communication Diagrams and Timing Diagrams.


The UML diagrams can be interchanged between tools with the “XML MetaInterchange“ (XMI) standard which makes using UML much more attractive.

UML has a mechanisms called “UML Profiles“ which allows the user to extendthe language. It has also an addition called “Object Constraint Language“(OCL). Using OCL the user can define logical expressions to create constrainson diagrams.

There are many tools with UML support. The well-known UML tools are:ARTISAN Studio from ARTISAN Software Tools [Art07], Enterprise Architectfrom Sparx Systems [Ent07], Telelogic TAU from Telelogic AB [Tel06], AltovaUModel from Altova Inc [Alt07], MagicDraw from No Magic [Mag07], VisualParadigm from Visual Paradigm International Ltd. [Vis07] and IBM RationalSoftware 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 wellas 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 sequencethey are executed or appeared, so Activity Diagrams depend on time. Theresponsibilities for an Action may also be modeled in the Activity Diagram bymeans of the element “Activity Partition“.

3.3. Meta model

The container element in the Activity Diagrams is the Activity. It contains theabstract classes Activity Edge, Activity Node and Activity Partition.

Each Activity may have multiple Activity Edges and Activity Nodes. TheActivity Nodes are connected via Activity Edges. Each Activity Node mayhave one or more incoming and outgoing Activity Edges. This is explained inmeta model in Figure 3.1, Activity Edge to Activity Node is modeled as * to 1relationship.

An Activity may have multiple Activity Partitions. In this case, ActivityNodes and Edges are contained in the Activity Partition.

There are two types of Activity Nodes: The Action Node and the ControlNode. The Action and Callbehavior Action are the different variants of the


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


3.3.1. Activity

The Activity is the root element in an Activity Diagram. It contains the wholeprocess consisting of Activity Nodes and Edges. An Activity begins with one ormultiple 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 Activityconnected by edges. [OMG07b, page 335]

It is a general class for nodes which are connected by Activity Edges. It coversthe Action Nodes and the Control Nodes.

3.3.3. Action Node

The Action Node is the central element in an Activity Diagram. It may becalled and executed. An Action Node may have several incoming and outgoingActivity Edges which establish the control flow between the nodes. The Actionand CallBehavior Action are specifications of the Action Node.

Action

The Action is a well-defined, basic step within an Activity and performs datamanipulation and processing. In the context of its parent Activity, it may not befurther decomposed. However, this does not mean that the Action is atomic. Inanother context, it could be described more precise. The notation for an Actionis 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 ratherthan invoking a behavioral feature that, in turn results in the invocation of thatbehavior. [OMG07b, page 248]


Figure 3.3.: Notation: CallBehavior Action

A CallBehavior Action contains other Actions. These Actions are called if theCallBehavior 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 waybetween Actions. [OMG07b, page 321]

Control Nodes organize the behavior of the flows in Activity Diagrams. Thereare 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. AnActivity can have more than one Initial Node. As Initial Nodes are the firstelements in an Activity. They may not have incoming control flows. Thenotation 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 itis the last element in a flow. Because of this character it has only incoming butno outgoing edges.

There may be multiple Final Nodes in an Activity Diagram. For example aftera flow splits into multiple flows the Activity may end in two or more differentvariants. There are to types of Final Nodes: Flow Final Node and Activity FinalNode.

Flow Final Node


A Flow Final Node terminates a flow and not the whole Activity. An Activitymay have multiple Flow Final Nodes. It destroys all the tokens in its flow, allthe other flows in the Activity remain unchanged and continue. The notation ofa Flow Final Node is a circle with an ”X” embedded, see Figure 3.5.

Figure 3.5.: Notation: Flow Final Node

Activity Final NodeAn Activity Final Node terminates all flows in an Activity. An Activity

may have multiple Activity Final Nodes. As soon as one Activity Final Nodeis reached, the remaining tokens are killed immediately and the executionterminates. The notation for an Activity Final Node is a circle containing a filledcircle, 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 guardexpressions of the outgoing Activity Edges is determine which flow should bepassed 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 parallelexecution of multiple edges is not allowed. A Decision Node is shown as anempty 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 DecisionNode into a single flow. So it has the opposite character of a Decision Node.


It has multiple incoming edges but only one outgoing edge. A Merge Node isnotated 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. TheDecision Node has one incoming edge and multiple outgoing edges. Merge nodehas 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 onconcurrently. A Fork Node has one incoming and multiple outgoing edges. Thenotation for a Fork Node is a vertical line, see Figure 3.10.

Figure 3.10.: Notation: Fork Node


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 DecisionNode splits the diagram into two subflows. Depending on the “Guard Expres-sions“ ([guard: x], [guard: y]) on the outgoing edges, it is determined whichsubflow has to be traversed. In the second model(see Figure 3.11, bottom), aFork Node splits the diagram into two synchronous subflows. If there is a parallelsplit, no guard conditions are needed.

Join Node

A Join Node is a control node which acts as the opposite of a Fork Node. It joinsthe synchronized flows to a single flow. Unlike the Fork Node, the Join Nodehas multiple incoming edges and one outgoing edge. A Join Node is shown witha 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. ActivityEdges are directed connections. Therefore their source and target element is an


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 controlmechanism for the transition of the Actions. If the Guard Expression is true, thetransition of the flow is allowed. Otherwise, (if it is false) the transition is notallowed [OMG07b]. The notation for an Activity Edge is a line with an arrowpointing 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 whichhave 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 Partitionsare used. All of the Actions have owners or responsibilities, they are marked withActivity Partitions in Activity Diagrams.

An Activity Partition is shown with two, parallel lines and a name labelingthe partition in a box at one end (see Figure 3.14). The parallel lines are calledswimlanes. They may be oriented horizontal or vertical. Activity Edges andnodes are positioned in the swimlanes.

Parallel and horizontal partition lines may be used together. Such an ActivityPartition is called multiple partition. This is the case if an Activity has morethan one owners or responsibilities.


Figure 3.15.: Notation: Multiple Activity Partition

3.5. Example Models

The example model scenario is equal to the examples of the Event-driven ProcessChains. Event-driven Process Chains from the Subsection 1.2 are transformedinto 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: HCPCPatient, HCPC Employee and HCPC Doctor. These are modeled with threeActivity Partitions which are modeled multi dimensional. In the Action ”Discusscost plan” both actors HCPC Employee and HCPC Patients are involved. Inthe Actions ”Discuss Care Plan”, ”Plan the non-medical care” and ”Plan themedical care” HCPC Doctor and HCPC Patient are involved. The ActivityPartitions can be modeled horizontally or vertically. The ”HCPC Patient” couldbe included in the horizontal box and the other involved actors in the verticalbox. That Activity Diagram would equal to the Event-driven Process Chainmodel in 2.4.

Unlike in Event-driven Process Chains, the decision and parallel flows do nothave to be joined back with a control node. In the model below, following theActivity ”Discuss care plan”, a parallel flow is introduced by a Fork Node. TheJoin Node however is optional, and could also be left out. Another difference toEvent-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 careapplies. Then a care and cost plan are decided. The costs of the care can betaken from the state or the patient has to pay himself.

The second model (Figure 3.17) explains a usual ”Home care” process. HCPCcare 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


When the home care activities are finished, they have to be documented andsent to the company.

Figure 3.17.: Example Model 2: Home Care

The third model (Figure 3.18) shows the process “Home care activities“ indetail. When the home care taker arrives at the patient a series of different careactivities are done. The medical care can be for example measuring the pulseof 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 caretaker can drive to the next patient.

Example models Example modelsin AD in EPC

Home Care Order Figure 3.16 Figure 2.17Home Care Figure 3.17 Figure 2.18

Home Care Activities Figure 3.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 isequal to which Event-driven Process Chain example mode. In the following sec-tion the mapping will be explained in detail.


Figure 3.18.: Example Model 3: Home Care Activities

47

Part III.

Transformation with Fujaba

48

4. Problem description

This section explains the conceptual mapping of Event-driven Process Chainsto Acitvity Diagrams. First, mappings are described on an element-to-elementlevel. A simple 1:1 mapping is not possible, because the same element may bemapped differently in a different context. For this reason, higher-level mappingvariants are also described. Therein, the mapping of several elements and theirrelationship to each other (model fragments) is documented. These fragmentswill 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 ProcessChain to Activity Diagram will be examined. Thereby, the scenarios will bemodeled conceptually without considering any transformation approach.

Elements of Event-Driven Process Chain Elements of Activity DiagramBasic Function Action

Complex Function Call Behavior ActionEvent Activity Edge, Initial Node,

Final NodeControl Flow Activity Edge

Organizational Flow -Logical Operator “AND“ Fork Node/ Join NodeLogical Operator “OR“ Fork Node/ Join Node

Logical Operator “XOR“ Decision Node/ Merge NodeOrganizational Unit Activity Partition

Table 4.1.: Mapping from Event-driven Process Chain to Activity Diagram

Elements of Activity Diagram Elements of Event-Driven Process ChainAction Basic Function

Call Behavior Action Complex FunctionActivity Edge 2 x Control Flow, EventInitial Node Event without incoming Control Flow

Activity Final Node Event without outgoing Control FlowFlow Final Node Event without outgoing Control Flow

Merge/Decision Node Logical Operator “XOR“Fork/Join Node Logical Operator “AND“, “OR“

4. Problem description 49

Activity Partition 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-drivenProcess Chain to Activity Diagram and vice versa.

A Basic Function and Complex Function are mapped to an Action and CallBehavior Action and vice versa respectively. An Event and a Control Flowis 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-drivenProcess Chain and two corresponding control nodes. The logical operators“AND“ and “OR“ are mapped to the same control node, namely Fork/JoinNode. The difference between “AND“ and “OR“ nodes is their handling ofguard expressions. If the guard expressions attached to the respective flows arethe 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 ControlFlow. The mapping of Final Nodes is exactly the opposite. They are againmapped as Events, but in this case as last Event of the diagram, with no outgoingControl Flow.

As the Activity Partition is modeled and illustrated as container element, theOrganizational Flow will not be mapped.

4.2. Mapping Variants

In this subsection simple element combinations in Event-driven Process Chainsand their transformation in Activity Diagrams will be shown in figures andexplained. This acts also as preparation for the Triple Graph Grammar rulesdescribed later on.

The element of Event-driven Process Chain and Activity Diagram cannotalways be mapped directly. In most cases the exact transformation depends onthe context of the element to be transformed. For example an Event can bemapped in several different ways because the predecessor and successor elementshave to be taken into consideration. Additionally to the one-to-one mappinglike described in tables 4.1 and 4.2 the elements themselves and their relationswill be mapped in the figures of this section. This is a useful preparation forthe definition of Triple Graph Grammar rules, because Triple Graph Grammarrules also include not only the isolated elements, but their relationships to otherelements as well.

There are some assumptions made for the transformation of Event-driven


Process Chains and Activity Diagrams. The Activity Diagrams cannot havemultiple Initial Nodes. According to that, Event-driven Process Chains have onestart and one end Event. The transformations shown in this subsection and thetransformation 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 modelfragments and their corresponding Activity Diagram sections are shown. Here,the element Event from Event-driven Process Chain is seen as central point ofthe model fragments. Based on that all possible combinations containing oneor 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 usedin this fragment. Every possible Event-driven Process Chain my be constructedusing 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. Thesecases are transformed to an Activity Diagram section where the Basic Functionsare mapped to Actions, Control Flows and Events are mapped to attributesof Activity Edges. The names of the Events are set as guard expression ofthe 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 Functionfollowed by an Event and Logical Operator (“AND“, “OR“, or “XOR“) to anAction followed by control nodes (Fork Node/Join Node, Decision Node/ MergeNode).

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, thelogical operator “AND“, “OR“ or “XOR“ is between a Basic Function and anEvent. It is notable that the Events are mapped to outgoing Activity Edges fromthe control node in Activity Diagrams. The name of the Event is again mappedas guard expression of the Activity Edge.


Figure 4.1.: Sections from EPC and AD


Figure 4.2.: Sections from EPC and AD (2)


Figure 4.3.: Sections from EPC and AD (3)


Figure 4.4 illustrates the beginning of a diagram. Event-driven Process Chainsalways start with an Event, Basic Functions are not allowed at the beginning. TheEvent 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 denotesthe beginning of the diagram. Therefore, Events without incoming Control Flowsare interpreted as beginning nodes and are mapped to Initial Nodes. The nameof the respective Event is also the name of the corresponding Initial Node. Afterthe 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 Chainsalso have to end with an Event. Correspondingly, Activity Diagrams also havea dedicated end node: Activity final node. (see Figure 4.5) Events withoutoutgoing Control Flows are mapped as Activity Final Nodes. Contrary to InitialNodes, all logical operators are allowed as predecessor of the last Event of thediagram.

An Event without an outgoing Control Flow can also be mapped to flow finalnode. 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


Figure 4.6.: Sections from EPC and AD: Event to Activity Final Node


nodes of Activity Diagram some additional information has to be given to thecorresponding Event of the Event-driven Process Chain. In the examples inthis section and in the transformation rules in Section 5 of this master thesis,such Events are named “FlowEnd“ to distinct final nodes when executing atransformation between Event-driven Process Chains and Activity Diagrams.

In Figure 4.7, no Events are included, because Organizational Units only applyto Basic Functions. One Organizational Unit can be connected to one or moreBasic Functions, and vice versa. The concept of this element is the same asActivity Partitions in Activity Diagrams. However, there is no flow connectionbetween Activities and Activity Partitions, because the partitions contain theActivities. The orientation (horizontal or vertical) of Activity Partitions is notof 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 ofthese logical operators have to be analyzed. As seen in Figure 4.8 the logicaloperator “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 distinctioncan be made when transforming from Activity Diagram to Event-driven ProcessChain. If “AND“ is also followed by two (or more) Events with different namesthe distinction of both logical operators would not work.


Figure 4.8.: Sections from EPC and AD: Distinction between “AND“ and “OR“

59

5. Triple Graph Grammars

This section provides an overview to Triple Graph Grammars. First, a comparisonto Pair Graph Grammars is given. After that, the mechanism of Triple GraphGrammar Rules is explained.

5.1. Pair Graph Grammars versus Triple GraphGrammars

The roots of triple graph grammars lead to “Pair Graph Grammars“, which wereintroduced by Pratt in 1971 [Pra71]. Pair Graph Grammars define a mappingbetween two subgraphs or a graph and a string within an overall graph. WithPair Graph Grammars graph-to-string or graph-to-graph transformations maybe done. Each vertex of the source and target models is mapped directly, sothat only 1 to 1 mapping relationship may be executed. Each Pair Graph Gram-mar rule consists of two graph productions: A graph production and a stringgraph 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 bySchürr [Sch95]. Schürr added a third subgraph to the transformation which iscalled “Correspondence Graph“. In contrast to Pair Graph Grammars, TGGscontain three graph productions. The two subgraphs in pair graph grammars act

5. Triple Graph Grammars 60

as left and right side in triple graph grammars. The relationship between the leftand right graph is established through the correspondence graph, which is shownin Figure 5.1. This correspondence graph enables to build n to m relationshipsbetween graphs, where multiple nodes on the left side correspond to multiplenodes on the right side. An example of this fact is the relationship of Events inEvent-driven Process Chains to Activity Edges. (One Activity Edge correspondsto 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 trans-formation rule tgg = consists of three graph transformationrules pleft, pright and pmap where pleft transforms the source model, pright trans-forms the target model and pmap transforms a relation model that maps source totarget elements. All three graph productions are applied simultaneously [GGL05].

The graph evolves gradually during the transformation using triple graphgrammar rules. The whole graph conforms to its schema at any time, as wellas the subgraphs involved on the left and right side. The correspondence graphkeeps track of the correspondences between the source and target graph nodes.From a model transformation point of view, the correspondence subgraph storesthe traceability information. Triple graph grammars support bidirectional andincremental model transformation because of the architecture involving thecorrespondence subgraph [Kön05].


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 rightside. Here the elements that will be transformed are modeled. On the left sidethe source model and its elements, on the right side, the target model and itselements are placed. The middle of each TGG rule is the corresponding part. Itconnects 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“ isthe root element. The element “A1“ of ModelA is mapped to the element “B1“of ModelB via the MappingNode “Cor1“. The MappingNode “Cor1“ containsthe tracing information of the elements “A1“ and “B1“.


Figure 5.3.: An example for a TGG rule

Figure 5.3 shows an example TGG Rule. It is based on mapping variant in Fig-ure 4.4. The source graph conforms to Event-driven Process Chains, the targetgraph to Activity Diagrams. Both are represented as graphs, with the source ele-ments on the left side and the target elements on the right side. Additionally, thecorrespondence graph is visible between the source and target graphs. The corre-spondence graph connects the related elements of the source and target graph. InFigure 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 adistinct 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 whichhave no parents or are not in a composite relationship.

In case of executing model transformations between Event-driven ProcessChain 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 identifiedwhich handles a possible transformation of this element.

For example e is a “Control Flow“ from Event-driven Process Chains. Thenall the rules which contain the Control Flow are identified.


3. For each identified TGG rule, it is checked whether the model requiresanother element created before e.

In order to create a Control Flow, a Basic Function and an Event have tobe created before.

4. If another element has to be created before, the transformation of e isstopped and will be done after the required element is handled. This ensuresthat the TGG rules are executed in the right order.

5. The whole process is repeated until no new output node is created by anyrule.

A summary about Triple Graph Grammars and Triple Graph Grammar Rulesis 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. (bidirec-tional model transformation)

• A triple graph grammar rule has always a source, a target and a correspon-dence part.

64

6. Developing Fujaba Plug-ins

This section explains how Fujaba Plug-ins are developed. First, an introductionto Fujaba in general is provided. After that, the different steps needed for im-plementing plug-ins are described. Also, source code examples are given, andproblems 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, thedevelopment continues in cooperation with many other universities, among themDarmstadt University of Technology and University of Kassel. Fujaba is anabbreviation for “From UML to Java And Back Again“. Figure 6.1 shows anoverview to the interface of Fujaba.

Figure 6.1.: An overview of Fujaba

Fujaba is written in Java. Therefore it is platform independent. It has anextendible architecture that provides the ability to add plug-ins. Fujaba supports

6. Developing Fujaba Plug-ins 65

forward engineering as well as reverse engineering. Models may be created fromJava code, and retrieved (see Figure 6.2).

Fujaba provides the Unified Modeling Language (UML) formalism for design-ing software. It supports many UML diagrams such as Class Diagram, StatechartDiagram, Package Diagram and Activity Diagram. Using them, structure andbehavior 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 pat-terns recognition with Fujaba [Fuj07d].

• Fujaba Real-Time Tool Suite: This project is for the model-driven specifi-cation and development of embedded real-time systems. Real-time systemsare intended for real time applications. The real-time systems are specifiedwith component diagrams from UML, Real-time coordination patterns, andReal-Time Statecharts. Component diagrams are needed to specify the ar-chitecture of the real-time systems and coordination patterns define thereal-time communication protocol. The behavior of a component or thebehavior of the roles of a real-time communication protocol are modeled bya Real-Time Statechart. The models are checked for correctness and areimplemented by code generation [Fuj07b].

• Education: The education project called “Life“ is applied at secondaryschools 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 Com-puter Science Lessons: Apply, Evaluate and Develop (further)“ [Fuj07a].

• ISILEIT: ISILEIT is an abbreviation for “Integrative Specification of Dis-tributed Control Systems for the Flexible Automated Manufacturing“. Thisproject aims at the development of a seamless methodology for the integrated


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 projectallows the user to execute model transformations using Triple Graph Gram-mars [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”(ModelRound-Trip Engineering) and ”MoTE” (Model Transformation Engine) andplug-ins, which are needed for Triple Graph Grammar Transformations. Theadditional code for plug-in is written using the Eclipse framework but any otherJava development environment may be used.

6.3. Steps to build the Event-driven Process Chainand Activity Diagram Plug-ins

Users should be able to create an Event-driven Process Chain and an ActivityDiagram with their basic elements. The elements included in these plug-insare those explained in the first part of the work. (see Section 2 and Section3). 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 adiagram type called “My Diagram” with only two basic elements: A node and anedge. Two nodes may be connected by an edge. The user may choose betweendifferent appearances of the elements; oval and rectangular. In Event-drivenProcess Chains and Activity Diagrams, this feature is not needed, so it is ignoredwhen implementing the plug-in. The approach used during development of theplug-ins is based on [Wen05]. This work provides a step by step description ofbuilding 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 abstractclass “de.upb.lib.plugins.AbstractPlugin” is extended. This class is defined inFujaba‘s library. This class is also the entry point for the plug-in.

1The current version is 5.0.4


Every Fujaba plug-in has to implement a main plug-in class. The mostconvenient way is to simply extend the abstract plug-in class, but it is alsopossible 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 Event-driven Process Chain and Activity Diagram are created with Fujaba’s classdiagram editor. The meta models modeled in Fujaba for the plug-ins are equalto 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 theproject’s preferences. This could be for example the location of the Eclipseworkspace. 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 handlemany important aspects of diagram features, for example loading and saving ofmodels. Therefore it is recommended to simply extend these provided abstractclasses.

6.3.3. Connecting to Fujaba´s Meta Model

Here, the Event-driven Process Chain and Activity Diagram elements areconnected to Fujaba´s “UMLClass“ by using the “Meta Model Integration


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 eachEvent-driven Process Chain and Activity Diagram element.

Listing 6.1: DeleteAction in Event-driven Process Chain plug-in

12 public class DeleteAction extends Abstractaction{34 public void actionPerformed(ActionEvent e){56 Object source=e.getSource ();78 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 }1718 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 eithera single element or an iterator over multiple elements. Depending on that, theelement or all elements contained in the iterator are removed with the methodremoveYou. Then, the elements marked are deleted. Finally, the display is beingrefreshed.

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 ActionEventcontains the marked diagram elements at the time the Action occurred. If morethan one diagram element is selected the object contains an iterator over theselected elements.

Listing 6.2: Adding a new FlowFinalNode as Action in Activity Diagram plug-in

12 public class NewADFlowFinalNodeAction extends

AbstractAction{3


4 public void actionPerformed(ActionEvent bFunction) {56 Object source = bFunction.getSource ();78 ActivityDiagram myDiagram = null;9 if (source instanceof ActivityDiagram)

10 {11 myDiagram = (ActivityDiagram) source;12 }13 else14 {15 source = UMLProject.get().getCurrentDiagram ();16 if (source instanceof ActivityDiagram)17 {18 myDiagram = (ActivityDiagram) source;19 }20 }2122 FlowFinalNode myNode = new FlowFinalNode ();23 myDiagram.addToElements (myNode);24 }25 }

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 Activ-ity 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 byextending 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 alreadyavailable classes may be used but in many cases it isnecessary to implementthese classes in order to create the desired appearance. Depending on the specialcase this is done either by extending the AbstractColorBorder class or otherSwing classes such as JCircle.

Listing 6.3: Drawing a Border for an Event in EPC Plug-in

1 public class EPCEventBorder extends AbstractColorBorder{2 ...34 public void paintBorder(Component c, Graphics g, int x,

int y, int width , int height)5 {6 Color oldColor = g.getColor ();


7 g.setColor(getBorderColor ());8 int newX[] = new int [7];9 int newY[] = new int [7];

10 newX [0]

on the usability of triple graph grammars for the ... · uml 2.x’in olaya- dayal sure˘ c...

Documents