Konzept und Implementierung von Swimlanes in ... · Zusammenfassung Ereignisgesteuerte...

Gottfried Wilhelm Leibniz Universitat Hannover

Fakultat fur Elektrotechnik und Informatik

Institut fur Praktische Informatik

Fachgebiet Software Engineering

Konzept und Implementierung von Swimlanes

in Ereignisgesteuerten Prozessketten

Bachelorarbeit

im Studiengang Informatik

von

Tristan Wehrmaker

Prufer: Prof. Dr. Kurt Schneider

Zweitprufer: Prof. Dr. Wolfgang Nejdl

Betreuer: Dipl.-Wirt.-Inform. Daniel Lubke

27. Februar 2007

Zusammenfassung

Ereignisgesteuerte Prozessketten konnen schnell sehr groß und unubersichtlichwerden. Je mehr Teilnehmer ein Prozess hat, desto sinnvoller ist es, diesen auseinem großen Prozess einzelne zugeschnittene Teilprozesse anzubieten. DieseArbeit befasst sich mit der Darstellung von Ereignisgesteuerten Prozesskettenin Swimlane-Diagrammen. Diese Swimlane-Darstellung kann eine erheblicheErleichterung fur die betroffenen Benutzergruppen bedeuten.

Abstract

Event-driven process chains can get very huge and unclear fastly. The moreparticipants a process has the sensiblier it is to offer them their own tailoredsubprocess from the huge one. This work deals with viewing event-driven pro-cess chains in swimlane-diagrams. The swimlane-view can give significant easeto all involved usergroups.

Danksagung

Ich danke Herrn Daniel Lubke,der mich bei meiner Bachelorarbeit

hervorragend betreut und unterstutzt hat.

Inhaltsverzeichnis

Inhaltsverzeichnis

1. Einleitung 81.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.2. Ziel dieser Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.3. Struktur dieser Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2. Grundlagen 102.1. Geschaftsprozesse und serviceorientierte Architekturen . . . . . . . . . . . . . . . . . . . . . . 102.2. Ereignisgesteuerte Prozesskette (EPK) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2.1. Elemente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2.2. Hierarchie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3. Swimlanes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.4. XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.5. EPC Markup Language (EPML) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.6. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3. Gegenuberstellung von EPK und UML 183.1. Unified Modeling Language (UML) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2. EPKs und UML-Aktivitatsdiagramme im Vergleich . . . . . . . . . . . . . . . . . . . . . . . . 193.3. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4. Konzeptionelle Untersuchung 214.1. Einfuhrung in das Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2. Nutzen von Swimlane-Diagrammen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.3. Empirische Validierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.3.1. Fragenblock 1: Swimlane-Darstellungen . . . . . . . . . . . . . . . . . . . . . . . . . . 234.3.2. Fragenblock 2: Hierarchien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.3.3. Fragenblock 3: AND-Join-Verknupfung . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.3.4. Fragenblock 4: Datenflusse bei Informationsobjekten . . . . . . . . . . . . . . . . . . . 29

4.4. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5. Darstellung von Swimlanes in Ereignisgesteuerten Prozessketten 305.1. Verwendete Variante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.2. Regeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.2.1. Grundlegende Regeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.2.2. Einfache Transformationsschritte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.2.3. Verknupfungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.3. Vorgehen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.4. Beispiel-Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.5. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5

Inhaltsverzeichnis

6. Implementierung 446.1. Zugrundeliegende Architekturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6.1.1. Eclipse und das Graphical Editing Framework (GEF) . . . . . . . . . . . . . . . . . . 446.1.2. ProFLOW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6.2. LaneEPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446.2.1. Verhaltnis zwischen den Plug-Ins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456.2.2. Interne Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456.2.3. Benutzerinteraktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6.3. Transformator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476.4. Erweiterungsmoglichkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6.4.1. Weitere Diagrammtypen und weitere EPK-basierte Prozesstypen . . . . . . . . . . . . 486.4.2. Editorenfenster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496.4.3. Verschiebung und Skalierung von Elementen . . . . . . . . . . . . . . . . . . . . . . . 496.4.4. EPK-Elemente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496.4.5. EPML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

6.5. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

7. Beispiel 517.1. Organisations-Swimlane-Diagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527.2. Informations-Swimlane-Diagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

8. Zusammenfassung und Ausblick 568.1. Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

A. Fragebogen 62

B. Beiliegende CD 67

6

Inhaltsverzeichnis

Akronyme

BPML Business Process Modeling Language

BPMN Business Process Modeling Notation

eEPK erweiterte Ereignisgesteuerte Prozesskette

EPK Ereignisgesteuerte Prozesskette

EPML Event-Driven-Process-Chain-Markup-Language

GEF Graphical Editing Framework

HTML Hypertext Markup Language

ISD Informations-Swimlane-Diagramm

OSD Organisations-Swimlane-Diagramm

SGML Standard Generalized Markup Language

SOA Serviceorientierte Architektur

UML Unified Modelling Language

XMI XML Metadata Interchange

XML Extensible Markup Language

7

1. Einleitung

1. Einleitung

1.1. Motivation

In Organisationen treffen immer wieder Mitglieder, die uber fachliches Wissen, und Mitglieder, die ubermethodisches oder technisches Wissen verfugen, aufeinander. Um die fachlichen Arbeitsablaufe zu definierenund an beide Mitgliedergruppen zu kommunizieren, werden Geschaftsprozessmodelle aufgestellt. Durch dieUnscharfe der naturlichen Sprache und der vermehrten Unbrauchbarkeit von mathematischen Formulierun-gen wird daher eine semiformale Beschreibungsform benotigt [ST05].

Als eine dieser Beschreibungsformen erfreut sich heute die Ereignisgesteuerte Prozesskette (EPK), beson-ders im deutschsprachigen Raum, einer breiten Akzeptanz. EPKs wurden 1992 in Zusammenarbeit mitder SAP AG an der Universitat des Saarlandes in Saarbrucken unter der Leitung von Prof. Dr. Dr. h.c.August-Wilhelm Scheer entwickelt. Mit Hilfe von EPKs konnen Geschaftsprozesse leicht verstandlich gra-phisch dargestellt werden. Mit steigender Komplexitat der EPKs kann die Ubersichtlichkeit immens sinken.Daher ware es wunschenswert, eine andere Darstellungsform zu finden, mit der auch große EPKs leichterlesbar werden.

Swimlane-Diagramme, wie sie schon aus UML oder BPMN bekannt sind, konnten eine solche Darstellungs-form bieten. Sie stellen eine Kombination aus Zustandigkeits- und Flussdiagramm dar. Dadurch ist es fur denBetrachter einer solchen Grafik leicht moglich, seine Rolle ausfindig zu machen, seine Verantwortlichkeitenund Entscheidungen zu identifizieren und die zeitliche Abfolge der Prozesse abzulesen.

1.2. Ziel dieser Arbeit

In dieser Arbeit soll nun untersucht werden, in welcher Form Swimlanes fur die Visualisierung von Ereig-nisgesteuerten Prozessketten geeignet sein konnen. Daruber hinaus wird ein Konzept aufgestellt, in dem dieUntersuchungsergebnisse beschrieben und umgesetzt werden sollen.

Zur Validierung dieses Konzepts soll im Anschluss ein Werkzeug entwickelt werden, das diese Visualisie-rung leistet. Vom Fachgebiet Software Engineering der Leibniz Universitat Hannover wird ein Plug-In furdie Entwicklungsumgebung Eclipse namens ProFLOW zur Verfugung gestellt, auf welchem das Werkzeugdieser Arbeit basieren soll.

1.3. Struktur dieser Arbeit

Diese Arbeit besteht aus acht Kapiteln. Zuerst werden in Kapitel 2 alle notigen Grundlagen eingefuhrt. Dazuwerden Geschaftsprozesse in Verbindung mit serviceorientierten Architekturen beschrieben, Ereignisgesteu-erte Prozessketten und Swimlanes erlautert, sowie die Beschreibungssprache EPML vorgestellt.

Nach dieser Einfuhrung folgt in Kapitel 3 eine Gegenuberstellung der Unified Modeling Language (UML)und der Ereignisgesteuerten Prozesskette (EPK). Hier wird UML und das dazugehorige Aktivitatsdiagramm

8

1. Einleitung

vorgestellt und dann mit der EPK verglichen.

Im Anschluss daran behandelt Kapitel 4 eine Einfuhrung in das Konzept, gefolgt von modelltheoretischenUntersuchungen und einer empirischen Befragung zur Validierung von ersten Konzeptansatzen.

In Kapitel 5 werden dann mogliche Darstellungen von Swimlanes beschrieben, sowie Regeln und Vorge-hensweisen zur Erstellung von Swimlane-Diagrammen vorgestellt.

Kapitel 6 behandelt die Implementierung dieses Konzepts in ein Plug-In fur die EntwicklungsumgebungEclipse. Dabei wird auf die zugrundeliegenden Architekturen eingegangen und der Aufbau des zu entwi-ckelnden Plug-Ins LaneEPC erlautert.

Nachdem die Implementierung abgehandelt wurde, wird im siebten Kapitel jeweils ein Beispiel fur einSwimlane-Diagramm, das mittels Organisationseinheiten aufgebaut ist, und ein Swimlane-Diagramm, dasmittels Informationsobjekten aufgebaut ist, in LaneEPC dargestellt.

Im Anschluss daran werden die durch diese Arbeit gewonnen Erkenntnisse zusammengefasst und ein Ausblickauf mogliche Erweiterungen des Konzeptes gegeben.

9

2. Grundlagen

2. Grundlagen

Dieses Kapitel wird einen Uberblick uber die Bereiche geben, die fur diese Arbeit grundlegend sind. Dazuwerden zuerst Geschaftsprozesse im Zusammenhang mit serviceorientierten Architekturen behandelt. Dabeiwird die Notwendigkeit fur die danach erlauterte Ereignisgesteuerte Prozesskette herausgestellt.

Im darauf folgenden Abschnitt werden dann Swimlanes anhand eines Beispiels aus der Unified ModelingLanguage vorgestellt.

2.1. Geschaftsprozesse und serviceorientierte Architekturen

Werden in einem Unternehmen Leistungen erstellt, laufen eine Vielzahl von Arbeitsschritten ab. Der Ablaufdieser Arbeitsschritte wird als Geschaftsprozess bezeichnet. Dabei finden sich heute in jedem UnternehmenGeschaftsprozesse, auch wenn diese insbesondere in kleinen Unternehmen nicht formal beschrieben werden.Besonders zur Optimierung der Geschaftsprozesse ist es aber von Nutzen, diese formal zu spezifizieren [Int06].Eine Definition der Geschaftsprozesse gibt Ulrich Frank in [FvL03]:

Definition 1 (Geschaftsprozess): Ein Geschaftsprozess ist eine wiederkehrende Abfolge von Aktivitaten,die mehr oder weniger rigiden Regelungsmustern genugt. Er ist zielgerichtet und steht in einem direktenZusammenhang mit der marktgerichteten Leistungserstellung eines Unternehmens. [. . . ] Die Ausfuhrungvon Geschaftsprozessen erfordert den Einsatz knapper Ressourcen.

Da Geschaftsprozesse also festlegen, welche Vorgange innerhalb eines Unternehmens durch welche Rollenausgefuhrt werden sollen [LGS05], wird sich diese Arbeit besonders mit diesen Rollen beschaftigen.

In vielen Fallen ist es nun sinnvoll, diese Geschaftsprozesse durch Softwaresysteme unterstutzen oder au-tomatisieren zu lassen. Da jedoch die Konfiguration und Anpassung von Standardsoftwarelosungen sehraufwandig und kostenintensiv ist, wird vermehrt auf sogenannte serviceorientierte Architekturen (SOA), wiezum Beispiel Web Services, gesetzt. Ziel der SOA ist es, eine Losung der Kopplung zwischen interagierendenSoftwareagenten zu erreichen.

Als Beispiel fur eine solche serviceorientierte Architektur konnte man einen Bonitats-Service nennen [Soi06].Ein solcher Service, der die Bonitat von Kunden prufen und in einer Vielzahl von Anwendungen benutztwerden soll, muss nur einmal bereitgestellt werden. Wird nun zum Beispiel ein neues Prufungsverfahreneingefuhrt, so wird der Service nur zentral angepasst und diese Anderung automatisch allen Anwendungenzur Verfugung gestellt. Die Anwendungen selbst mussen nicht angepasst werden.

In SOA mussen Business-Funktionen nicht neu programmiert, sondern nur orchestriert, also nur noch exis-tierende Services neu zusammengestellt, werden. So ist es leicht moglich, Programmteile auszutauschen,bzw. den gesamten Prozess umzustellen. Eine Moglichkeit, die Anforderungen fur solche Orchestrierungenaufzustellen, sind die Ereignisgesteuerten Prozessketten, welche im folgenden Abschnitt erlautert werden.

10

2. Grundlagen

2.2. Ereignisgesteuerte Prozesskette (EPK)

Die Ereignisgesteuerte Prozesskette wurde 1992 am Institut fur Wirtschaftsinformatik der Universitat desSaarlandes in Saarbrucken, in Zusammenarbeit mit der SAP AG, entwickelt. Ihr Ziel ist die Dokumentationvon Geschaftsprozessen [KNS92].

Sie besteht im Wesentlichen aus den Elementen Funktion, Ereignis, Prozesswegweiser und drei Arten vonVerknupfungen, welche im folgenden Abschnitt vorgestellt werden. Von einer formalisierten Erlauterung derSyntax und Semantik wird hier aus Platzgrunden Abstand genommen. Ausfuhrliche Informationen hierzufinden sich in [NR02].

Abbildung 2.1.: Metamodell einer EPK in Anlehung an [Lub06]

2.2.1. Elemente

Funktion

Der Begriff der Funktion kann auf verschiedene Arten definiert werden. So wird der Begriff in der Mathematikals eine Vorschrift angesehen, in der jedem Element einer Menge genau ein Element einer zweiten Mengezugeordnet wird. Hier wird der Begriff Funktion vielmehr als eine Aufgabe, d.h. als physische oder geistigeAktivitat zur Erfullung eines definierten Soll-Zustands, verstanden.

Abbildung 2.2.: Funktion

11

2. Grundlagen

Funktionen stellen dabei die einzigen aktiven Elemente in einer Ereignisgesteuerten Prozesskette dar. Aus-serdem konnen Funktionen weitere Prozesse beinhalten. Diese Tatsache wird in Abschnitt 2.2.2 beschrieben.Als Symbol fur eine Funktion wird in der EPK ein abgerundetes Rechteck verwendet.

Ereignis

In Anlehnung an die DIN 69900-1 ist ein Ereignis das Eingetretensein eines definierten Zustands, der eineFolge von Aktivitaten bewirkt [KNS92].

Ereignisse werden dabei durch folgende Eigenschaften gekennzeichnet:

• Ereignisse reprasentieren einen eingetretenen Zustand.

• Ereignisse dienen zur Spezifikation betriebswirtschaflicher Bedingungen.

• Ereignisse konnen Funktionen auslosen.

• Ereignisse konnen Prozesswegweiser auslosen.

• Funktionen werden durch Ereignisse ausgelost.

• Prozesswegweiser werden durch Ereignisse ausgelost.

Abbildung 2.3.: Ereignis

Abbildung 2.3 zeigt exemplarisch die Darstellung eines Ereignis-Elements als Hexagon.

Prozesswegweiser

EPK-Modelle konnen durch Prozesswegweiser in Beziehung zueinander gesetzt werden. Dabei werden sieals Verbindung zu Vorganger- bzw. Nachfolgerprozessen verwendet. Prozesswegweiser haben entweder genaueine eingehende oder genau eine ausgehende Kante, daher konnen sie nur am Anfang oder am Ende einerEreignisgesteuerten Prozesskette stehen.

Abbildung 2.4.: Prozesswegweiser

Als Symbol fur einen Prozesswegweiser wird in der EPK ein Ereignissymbol und ein Funktionssymbol uber-lappend dargestellt (siehe Abbildung 2.4).

Verknupfungen

In Ereignisgesteuerten Prozessketten existieren drei Verknupfungsarten, um Ereignisse, Funktionen und Pro-zesswegweiser zu verknupfen. Als Verknupfung werden die AND-, OR- und XOR-Operatoren der booleschenAlgebra verwendet. Dabei mussen auf den Seiten der Verknupfung jeweils unterschiedliche Elemente stehen.

12

2. Grundlagen

So muss zum Beispiel, wenn Funktionen miteinander verknupft werden, ein Ereignis folgen. Die drei Ver-knupfungsarten werden in Tabelle 2.1 zusammengefasst.

Desweiteren wird zwischen Split- und Join-Verknupfungen unterschieden. Dabei wird mittels Split-Verknupf-ungen der Prozess in mehrere Pfade geteilt und mittels Join-Verknupfungen wieder zusammengefuhrt. DaEreignisse keine Entscheidungen treffen konnen, durfen auf diese ausserdem keine OR- oder XOR-Split-Verknupfungen folgen. Solche sind nur nach Funktionen erlaubt [KNS92].

Operator Beschreibung Symbol

konjunktiv (AND) Eine Aussage ist wahr, wenn alle Teilaussagen wahr sind.

adjunktiv (OR) Eine Aussage ist wahr, wenn min. eine Teilaussage wahr ist.

disjunktiv (XOR) Eine Aussage ist wahr, wenn genau eine Teilaussage wahr ist.

Tabelle 2.1.: Verknupfungen

Erweiterte Ereignisgesteuerte Prozesskette

Im Folgenden werden drei Arten von Objekten beschrieben, welche im Zuge der erweiterten Ereignisge-steuerten Prozesskette (eEPK) zur Definition von EPKs hinzugefugt worden sind. Diese Objekte stehen imMittelpunkt der in dieser Arbeit aufgestellten Untersuchungen.

Abbildung 2.5.: eEPK-Elemente

Die in Abbildung 2.5 dargestellten Objekte konnen nur mit Funktionen, aber nicht mit Ereignissen verbun-den sein. So ist es fur den Geschaftsprozess nur relevant, welche Informationen fur die Ausfuhrung einerFunktion benotigt werden, wer diese Funktion ausfuhrt und ob eine Anwendung dafur benotigt wird. Es istaber nicht von Relevanz, wer z.B. ein Ereignis ausgelost hat.

Organisationseinheiten stehen fur Personen oder Abteilungen, die an einer Funktion beteiligt sind. Infor-mationsobjekte stellen ein Datenobjekt dar. Dies konnen zum Beispiel Dokumente oder Datenbanken sein.Desweiteren konnen Anwendungen, also unterstutzende Softwaresysteme, an Funktionen beteiligt sein.

Dabei werden Organisationseinheiten und Anwendungen durch einfache Linien mit den Funktionen verbun-den. Bei Informationsobjekten werden zur Kennzeichnung der Richtung des Datenflusses Pfeile verwendet.

13

2. Grundlagen

2.2.2. Hierarchie

Man unterscheidet zwischen flachen und hierarchischen Ereignisgesteuerten Prozessketten. Dabei bestehenflache EPKs nur aus einer Ebene und stellen damit den trivialen Fall einer EPK dar. In den meisten Fal-len verhalt es sich allerdings so, dass eine Funktion in einen bzw. mehrere Prozesse untergliedert werden kann.

Abbildung 2.6 zeigt exemplarisch diesen Sachverhalt. Die Funktion ”Bestellung bearbeiten“ wird dabei inder nachsten Hierarchieebene weiter unterteilt und so detailliert. So konnte man sich zum Beispiel vorstellen,dass die Funktion ”Artikel versenden“ auch noch weiter prazisiert wird.

Abbildung 2.6.: Fallbeispiel ”Bestellung“

2.3. Swimlanes

Swimlanes - in der Literatur auch Schwimmbahn [Jec], Verantwortlichkeitsbereich [BRJ99] oder Partition[Obj05] genannt - sind eine Darstellungsmoglichkeit fur Verantwortlichkeiten, wie sie zum Beispiel aus UMLoder der BPMN bekannt ist. Sie zeigen dem Betrachter sehr direkt auf, wofur er die Verantwortung tragt.Dabei werden den verschiedenen Beteiligten - zum Beispiel Abteilungen - in der graphischen Darstellung desGeschaftsprozesses einzelne Bereiche zugeordnet. In Anlehnung an [Boo01] kann folgende Definition gegebenwerden:

14

2. Grundlagen

Definition 2 (Swimlane): Ein Swimlane-Diagramm ist eine Abbildung zum Darstellen von Folgen von Auf-gaben und Entscheidungen in einem Prozess. [...] Die horizontale Dimension des Swimlane-Diagramms be-zeichnet die Zeit. Die vertikale Dimension besteht aus Bandern oder Schwimmbahnen, wobei jede Schwimm-bahn fur eine Organisation oder eine spezielle Rolle steht. Die Aufgaben werden von den Organisationen(Schwimmbahnen) ausgefuhrt, in denen sie sich befinden.

Dabei sei angemerkt, dass die in dieser Definition angegebene Ausrichtung der horizontalen und vertikalenDimensionen in dieser Ausarbeitung vertauscht wird. Es ist in Ereignisgesteuerten Prozessketten allgemeinublich, dass die vertikale Achse die Zeit darstellt.

Abbildung 2.7.: Darstellung eines UML-Aktivitatsdiagramms in Swimlanes in Anlehnung an [BRJ99]

Abbildung 2.7 verdeutlicht den Vorteil einer Einteilung in Swimlanes am Beispiel eines UML-Aktivitats-diagramms. Auf der linken Seite sieht man die ubliche Notation eines Aktivitatsdiagramms, auf der rechten

15

2. Grundlagen

Seite ist der Graph um Swimlanes fur die Organisationseinheiten Kunde, Vertrieb und Lager erweitert. So-mit konnen die Angehorigen dieser Organisationseinheiten auf einen Blick ihre Aufgaben und den zeitlichenAblauf ablesen. Dabei sind Swimlanes in UML-Aktivitatsdiagrammen die einzige Moglichkeit, Verantwort-lichkeiten darzustellen.

2.4. XML

Die Extensible Markup Language (XML) wurde 1996 vom W3 Consortium entwickelt. Sie ist dabei abgeleitetvon SGML, auf welcher zum Beispiel auch die Hypertext Markup Language (HTML) basiert. XML wurdemit den folgenden Zielen definiert [W3C06]:

• XML soll direkt uber das Internet verwendbar sein.

• XML soll eine Vielzahl von Anwendungen unterstutzen.

• Programme, die XML-Dokumente verarbeiten, sollen einfach zu schreiben sein.

• XML-Dokumente sollen fur den Menschen lesbar und halbwegs anschaulich sein.

• Das Design von XML soll formal und prazise sein.

• XML-Dokumente sollen leicht erstellt werden konnen.

Auf Basis von XML sind mit der Zeit viele Formate fur spezielle Anwendungsfalle entstanden. Bei diesenunterscheidet man zwischen schwacher und starker Standardunterstutzung [MN03].

Eine schwache Standardunterstutzung ist gekennzeichnet durch ein produktabhangiges und damit proprieta-res XML Schema. Dadurch kommt es zu einer Vielzahl von heterogenen Werkzeugen, die alle unterschiedli-che XML-Formate unterstutzen, unter welchen mittels Transformationsprogrammen vermittelt werden muss.Starke Standardunterstutzung hingegen setzt auf anerkannte XML-Austauschformate, so konnen Werkzeugedurch andere ersetzt werden, ohne dass sich an den Daten etwas andert.

Fur diverse Modellierungskonzepte haben sich derartige Standards heute etabliert, so zum Beispiel XMLMetadata Interchange (XMI) fur UML, die Business Process Modeling Language (BPML) fur die BusinessProcess Modeling Notation (BPMN) und auch die Event-Driven-Process-Chain-Markup-Language (EPML)fur Ereignisgesteuerte Prozessketten, welche im nachsten Abschnitt beschrieben wird.

2.5. EPC Markup Language (EPML)

Listing 2.1 gibt einen Uberblick uber die Elemente von EPML. Dabei soll hier nur kurz auf die wichtigstenElemente eingegangen werden. Eine ausfuhrliche Beschreibung findet sich in [MN05].

Das epml-Element stellt das Rootelement dar. Uber das graphicsDefault-Element konnen verschiedene gra-phische Richtlinien festgelegt werden, welche dann von Visualisierungswerkzeugen verwendet werden konnen.Die Einstellungen gelten fur alle EPK-Elemente, sofern fur diese im graphics-Element keine Informationenhinterlegt sind.

Das directory-Element kann die Ereignisgesteuerten Prozessketten als epc-Elemente, sowie weitere directory

-Elemente enthalten. Auf diese Weise werden in EPML hierarchische EPKs realisiert. Im epc-Element findensich die Ereignisse, Funktionen, Verknupfungen usw.

16

2. Grundlagen

Wird ein EPK-Element in mehreren EPK-Modellen verwendet - wie z.B. bei hierarchischen EPKs -, konnenReferenzen erstellt werden. Dies geschieht durch das definitions-Element.

epmldocumentation?toolInfo?graphicsDefault?

fill? (color, image, gradient-color, gradient-rotation)line? (shape, width, color, style)font? (family, style, weight, size, decoration, color, verticalAlign, horizontalAlign,

rotation)coordinates (xOrigin, yOrigin)definitions?

definition* (defId)namedescription

attributeTypes?attributeType* (typeId)

descriptiondirectory (name)

directory* (name) ...epc* (epcId, name)

attribute* (typeRef, value)event* (id, defRef) ...function* (id, defRef)

namedescription?graphics?

position? (x, y, width, height)fill? (color, image, gradient-color, gradient-rotation)line? (shape, width, color, style)font? (family, style, weight, size, decoration, color, verticalAlign,

horizontalAlign, rotation)syntaxInfo? (implicitType)toProcess? (linkToEpcId)attribute* (typeRef, value)

processInterface* (id, defRef) ...and* ...or* ...xor* ...arc* ...application* ...participant* ...dataField* ...relation* ...

Listing 2.1: EPML-Elemente als Syntax-Baum

2.6. Zusammenfassung

In diesem Kapitel wurde in die fur diese Arbeit wichtigen Grundlagen eingefuhrt. Dazu wurde der BegriffGeschaftsprozess und dessen Verbindung zu serviceorientierten Architekturen vorgestellt. Hier wurde gezeigt,welche Vorteile diese Architekturen bieten konnen.

Im Anschluss daran wurde die Ereignisgesteuerte Prozesskette, sowie deren Elemente und die Bedeutung derHierarchien beschrieben. Danach wurde die Swimlane-Darstellung anhand eines UML-Aktivitatsdiagrammsvorgestellt.

Zum Abschluss dieses Kapitels wurde dann die Extensible Markup Language (XML) in Zusammenhangmit schwacher und starker Standardunterstutzung erlautert und mit dem im darauffolgenden Abschnitterlauterten XML-Dialekt fur Ereignisgesteuerte Prozessketten (EPML) in Verbindung gebracht.

17

3. Gegenuberstellung von EPK und UML


In diesem Kapitel sollen nun die Konzepte der Unified Modelling Language (UML) und der Ereignisgesteu-erten Prozesskette gegenubergestellt werden. Dazu soll gezeigt werden, in welchen Fallen welches Konzeptgenutzt wird.

3.1. Unified Modeling Language (UML)

Die Unified Modeling Language wurde von der Object Management Group (OMG) entwickelt und standar-disiert. Dabei stellt die UML heute eine der dominierenden Sprachen zur Modellierung von Softwaresystemendar. So bietet sich durch ihre objektorientierte Modellierung eine Verbindung zu objektorientierten Program-miersprachen wie Java und C++. Diese Verbindung wird oftmals durch Codegeneratoren genutzt, um dieUML-Modelle in Code der jeweiligen Programmiersprache zu konvertieren.

In der aktuellen Version 2.0 besteht die UML aus dreizehn Diagrammtypen, dabei unterscheidet man zwi-schen Strukturdiagrammen und Verhaltensdiagrammen [Obj05].

Strukturdiagramme:

• Klassendiagramm (class diagram)

• Kompositionsstrukturdiagramm (composite structure diagram)

• Komponentendiagramm (component diagram)

• Verteilungsdiagramm (deployment diagram)

• Objektdiagramm (object diagram)

• Paketdiagramm (package diagram)

Verhaltensdiagramme:

• Aktivitatsdiagramm (activity diagram)

• Interaktionsdiagramme (interaction diagrams):

– Sequenzdiagramm (sequence diagram)

– Kommunikationsdiagramm (communication diagram)

– Interaktionsuberblickdiagramm (interaction overview diagram)

– Zeitverlaufsdiagramm (timing diagram)

• Anwendungsfalldiagramm (use case diagram)

• Zustandsdiagramm (state machine diagram)

Aus dieser Vielzahl von Diagrammarten kommen die Aktivitatsdiagramme den Ereignisgesteuerten Prozess-ketten am nachsten. Eine Gegenuberstellung dieser beiden Diagramme befindet sich im folgenden Abschnitt.

18


3.2. EPKs und UML-Aktivitatsdiagramme im Vergleich

Zu Beginn dieser Gegenuberstellung soll nun zuerst auf die Unterschiede und Ahnlichkeiten in den Notatio-nen von UML-Aktivitatsdiagrammen und Ereignisgesteuerten Prozessketten eingegangen werden. Danachwerden die Einsatzgebiete dieser Modellierungen beschrieben.

Abbildung 3.1.: Gegenuberstellung - EPK (links) und UML 2.0 Aktivitatsdiagramm (rechts)

In Abbildung 3.1 wird ein Geschaftsprozess auf zwei verschiedene Weisen dargestellt. Links sieht man dieDarstellung als Ereignisgesteuerte Prozesskette und rechts als UML-Aktivitatsdiagramm. Die Abbildungbeschreibt einen Geschaftsprozess, in dem die Bearbeitung einer Bestellung formuliert ist. Dabei zeigen sichschon auf den ersten Blick mehrere Unterschiede in der Notation:

19


• Die Organisationseinheiten werden in EPKs als Elemente an die Funktionen geschrieben. In UMLhingegen ist nur eine Notation in Swimlanes moglich.

• Die in EPKs verwendeten Ereignisse treten in UML nicht auf. Sie werden hier indirekt durch Zustand-stransitionen modelliert.

• XOR-Verknupfungen werden in UML durch sogenannte Entscheidungskristalle realisiert. Eine Bedin-gung fur die Entscheidung wird ggf. an der folgenden Transition vermerkt.

• AND-Verknupfungen werden in UML als Parallelisierungs- bzw. Synchronisationsbalken dargestellt.

• Fur OR-Verknupfungen gibt es in der UML keine eigene Notation. Diese konnen lediglich durch Be-dingungen an Synchronisationsbalken dargestellt werden.

• Informationsobjekte werden in UML nicht, wie in EPKs an die betreffende Funktion notiert, sondernstehen als eigenstandige Objekte im Kontrollfluss.

Desweiteren sind in UML-Aktivitatsdiagrammen keine Zuordnungen von Daten zu Aktionen moglich, wo-durch Geschaftsregeln nur eingeschrankt darstellbar sind [Dan99].

Ursprunglich liegt der Verwendungszweck der Unified Modeling Language in der Modellierung von Soft-waresystemen. Die Modellierung von Geschaftsprozessen war zum Einen nicht vorgesehen und zum Anderennur schwer moglich. Um dieses Manko zu beseitigen und den Markt der Geschaftsprozesse zu erschließen,wurden in der Spezifikation zu UML in der Version 2.0 einige Erweiterungen zur Notation von Aktivitats-diagrammen hinzugefugt.

Der ursprungliche Verwendungszweck der Ereignisgesteuerten Prozesskette und damit auch ihre Starke liegtin der Modellierung von Geschaftsprozessen. Somit ist keine implementierungsnahe Modellierung vorgesehen,wie sie von UML forciert wird.

Die Unified Modeling Language wird traditionell hauptsachlich im Umfeld des Software-Engineerings ver-wendet. Demgegenuber hat sich die Ereignisgesteuerte Prozesskette besonders ausserhalb des Software-Engineerings einen Namen gemacht. Dies liegt wohl vor allem daran, dass in der UML Ablaufe sehr granularbeschrieben werden, wie es fur Softwaresysteme gebraucht wird. Die Ereignisgesteuerte Prozesskette hingegendient viel mehr der Beschreibung von Anforderungen fur Softwaresysteme. Dadurch ist vor allem interessant,was ein System bzw. ein Benutzer des Systems in einer bestimmten Situation macht - nicht jedoch wie esbzw. er dies macht.


In diesem Kapitel wurde ein kurzer Einblick in die Unified Modeling Language (UML) gegeben. Im Anschlussdaran wurden die Notationen von Ereignisgesteuerten Prozessketten und UML-Aktivitatsdiagrammen vergli-chen und die Unterschiede dargelegt. In der darauf folgenden Beschreibung des Verwendungszweckes hat sichherausgestellt, dass UML-Aktivitatsdiagramme ihre Verwendung in der Modellierung von Softwaresystemenfindet. Hingegen werden Ereignisgesteuerte Prozessketten fur die Modellierung von Geschaftsprozessen undzur Notation von Anforderungen fur Softwaresysteme verwendet.

20

4. Konzeptionelle Untersuchung


In diesem und dem darauffolgenden Kapitel soll nun ein Konzept entworfen werden, das es ermoglicht, Ereig-nisgesteuerte Prozessketten mit Hilfe von Swimlanes darzustellen. Dazu wird zuerst eine kurze Einfuhrungin das Konzept gegeben, woraufhin dann im Folgenden der Nutzen von Swimlanes in EPKs beschriebenwird. Im Anschluss daran wird auf eine empirische Befragung, welche zu dieser Arbeit durchgefuhrt wurde,eingegangen.

4.1. Einfuhrung in das Konzept

Das Ziel dieses Konzeptes soll es sein, die Ereignisgesteuerte Prozesskette, als eine abstrakte Beschreibungeines Geschaftsprozesses, von der klassischen EPK-Darstellung in eine Swimlane-Darstellung zu transferieren.Abbildung 4.1 zeigt diesen Sachverhalt. Dabei stellt der untere Kasten die Ereignisgesteuerte Prozesskettedar. Auf der linken Seite findet man die klassische Darstellung fur EPKs und auf der rechten Seite symbolischdie hier zu entwickelnde Swimlane-Darstellung. In den folgenden Abschnitten werden dazu mehrere Ansatzevorgestellt.

Abbildung 4.1.: Konzept

21


Auf dem Softwaremarkt vertreibt die Firma Gedilan die Software Nautilus, die Ereignisgesteuerte Prozess-ketten als Swimlane-Diagramme darstellen kann [Ged]. Allerdings ist es hier nicht einfach moglich, zwi-schen den verschiedenen Darstellungen zu wechseln. Dabei handelt es sich hierbei vielmehr um ein kom-plettes Managment-System, daher kann man EPKs nicht selber zeichnen, sondern nur fertig eingegebeneGeschaftsprozesse anzeigen bzw. sich daraus Prasentationen erstellen lassen. Der Ansatz zur Darstellung vonSwimlanes, den Nautilus verwendet, lehnt sich stark an die aus UML bekannte Notation an.

In die entgegengesetzte Richtung geht zum Beispiel Microsoft Visio, mit dem nur die reine Zeichnung der Er-eignisgesteuerten Prozessketten moglich ist [Mic]. Dabei existieren keinerlei Automatismen zur Syntaxuber-prufung oder zur Darstellung als Swimlane-Diagramm. Letzteres ist nur unter Verwendung der UML-Shapesfur Swimlanes moglich. Daher unterscheidet es sich nicht von normalen Zeichenprogrammen, wie dem vorallem unter Linux bekannten Dia Diagrammeditor [Lar].

4.2. Nutzen von Swimlane-Diagrammen

In diesem Abschnitt soll beantwortet werden, fur wen die Modellierung von Swimlanes in EreignisgesteuertenProzessketten von Nutzen ist und welche Qualitatsmerkmale von Bedeutung sind.

In erster Linie kann man sich vorstellen, dass Swimlanes fur die Betrachter von Geschaftsprozessdiagrammeneine erhebliche Erleichterung darstellen konnen. So mussen diese ihre Konzentration nur auf ihren Bereichrichten. Damit ist fur sie nur relevant, was ausserhalb ihrer Bereiche passiert, wenn sie mit anderen gemein-sam an einer Aufgabe arbeiten.

Auf Seiten des Modellierers ist es naturlich sehr wunschenswert, den Beteiligten auf sie zugeschnitteneProzesse bieten zu konnen. Dadurch stellt sich eine erhebliche Kosten- und Zeitersparnis heraus. Es kommtzwar ein geringer Zeitaufwand auf den Modellierer zu, allerdings konnen sich so die Beteiligten schnellerauf den Prozess einstellen. Die Mehrkosten eines Modellierers bzw. einer Modellierergruppe stehen so denMinderkosten aller anderen Beteiligten gegenuber.

Von hochster Bedeutung fur den Nutzen von Swimlanes in Ereignisgesteuerten Prozessketten ist, so we-nig Veranderungen wie moglich an der Notation von EPKs vorzunehmen, um die Einstiegshurden moglichstgering zuhalten. So sollte die Darstellung besonders fur Nutzer, die keine Erfahrungen in der Modellierungvon Geschaftsprozessen haben, keine große Umstellung sein.

4.3. Empirische Validierung

Zur Validierung des hier vorgestellten Konzeptes wurde im Rahmen des Projektes ”Entwicklung einerWebservice-basierten Anwendung“ im Fachgebiet Software Engineering der Leibniz Universitat Hannovereine empirische Befragung durchgefuhrt. In dieser Befragung haben zehn Projektteilnehmer Grundsatzfra-gen bezuglich des Konzeptes beantwortet. Der verteilte Fragebogen bestand aus vier Frageblocken, welcheim Folgenden erlautert werden. Die in diesem Abschnitt gezeigten Abbildungen sind im Gegensatz zu denAbbildungen im Fragebogen aus Platzgrunden teilweise gekurzt. Der vollstandige Fragebogen findet sich imAnhang dieser Arbeit.

22


4.3.1. Fragenblock 1: Swimlane-Darstellungen

Der erste Fragenblock behandelt eine Gegenuberstellung der moglichen Swimlane-Darstellungen. Abbildung4.2 zeigt die fur diesen Fragenblock zugrundegelegte Ereignisgesteuerte Prozesskette, in der das Eingeheneines Kundenauftrages bearbeitet wird. Dazu sollten die Befragten ihre Meinung zu den Bereichen Uber-sichtlichkeit, Brauchbarkeit (beim Betrachten) und mogliche Handhabbarkeit (beim Erstellen) in Schulnotenausdrucken.

Abbildung 4.2.: zugrundeliegende EPK

Anschließend war eine bevorzugte Variante zu wahlen. Besonders interessant ist bei diesem Block, dass oft-mals eine Variante als Bevorzugte ausgewahlt wurde, welche bei der Bewertung nach Schulnoten schlechterausgefallen ist. Weiter wurde in diesem Block danach gefragt, fur wen das Konzept der Swimlanes interessantsein konnte.

Die in diesem Fragenblock behandelten Varianten sollen nun beschrieben werden:

Variante 1: Anlehnung an UML-Swimlanes

Eine Moglichkeit, Swimlane-Diagramme darzustellen, ist, wie bei Aktivitatsdiagrammen der Unified Mode-ling Language vorzugehen. Dabei werden die Elemente der zugrundegelegten EPK einfach in die jeweiligenSwimlanes verschoben. Daher uberschneiden die Transitionen die Grenzen der Swimlanes und sorgen so invielen Fallen fur unubersichtliche Diagramme.

23


Wie man in Abbildung 4.3 sieht, konnen hier, insbesondere im Falle von Verknupfungen, semantische Unklar-heiten auftreten. So lassen sich Verknupfungen oftmals nicht eindeutig einem einzelnen Bereich zuordnen.Ein weiterer Nachteil dieser Darstellung ist, dass die Swimlane-Bereiche nicht unabhangig voneinander be-trachtet werden konnen.

Abbildung 4.3.: Variante 1: Anlehnung an UML-Swimlanes

Bei den Befragten konnte diese Variante lediglich in der Handhabbarkeit fur den Modellierer punkten. Dieslasst sich auch leicht begrunden, da der Modellierer beim Erstellen eines solchen Diagramms nur wenigeRegeln einhalten muss. Bei der Frage nach der bevorzugten Variante haben sich erstaunlicherweise 50% derBefragten fur diese Variante entschieden, wobei sie in der Bewertung nach Schulnoten eher mittelmassigabgeschnitten hat.

24


Variante 2: passive Swimlanes

Eine weitere Moglichkeit wird in Abbildung 4.4 dargestellt. Hierbei handelt es sich um passive Swimlanes.In dieser Darstellung enthalten die Swimlanes keine aktiven Elemente (Funktionen etc.), sondern nur dieOrganisationseinheiten bzw. Informationsobjekte.

Abbildung 4.4.: Variante 2: passive Swimlanes

Diese Darstellung stellt die geringste Veranderung der klassischen EPK-Darstellung dar. Durch die Verla-gerung der Organisationseinheiten bzw. Informationsobjekte ausserhalb der EPK, wird eine Vielzahl derDiagramme wahrscheinlich weitaus unubersichtlicher. Dies ist wohl auch der Grund, warum diese Varian-te in der empirischen Validierung mit Abstand am schlechtesten abgeschnitten hat. Sie wurde von keinemBefragten als Bevorzugte gewahlt.

25


Variante 3: Unabhangige Teilprozesse

In Verbindung mit ”My own process: Providing dedicated views on EPCs“ [GRvdA05] und ”Multiperspek-tivische ereignisgesteuerte Prozesskette“ [BDFK03] kann diese Variante abgeleitet werden. Dabei wird jedebeteiligte Organisationseinheit bzw. jedes Informationsobjekt einzeln betrachtet und fur diese ein eigenerTeilprozess zugeschnitten.

Abbildung 4.5 zeigt exemplarisch eine solche Darstellung. Der Vorteil dieser Variante ist, dass in den Swim-lanes vollwertige Prozesse stehen, die unabhangig von den Nachbarswimlanes betrachtet werden konnen.

Abbildung 4.5.: Variante 3: Unabhangige Teilprozesse

Diese Variante hat insbesondere bei der Frage nach der Ubersichtlichkeit sehr gut abgeschnitten. Allerdingswurde sie nur von einem Befragten als Bevorzugte gewahlt.

26


Variante 4: Unabhangige Teilprozesse mit Wartezeitmarkierungen

In Variante 4 wird Variante 3 um Verbindungskanten erweitert. Dabei werden, im Falle von Unterbrechun-gen des Prozesses in einer Swimlane, Kanten eingefuhrt. Diese Kanten symbolisieren die Wartezeit, bis derTeilnehmer wieder weitermachen kann.

Abbildung 4.6.: Variante 4: Unabhangige Teilprozesse mit Wartezeitmarkierungen

Diese Variante unterscheidet sich nicht sehr von Variante 3. Um so erstaunlicher ist das Ergebnis der Befra-gung. Dabei hat diese Variante in der Ubersichtlichkeit und Brauchbarkeit beim Betrachten bessere Noten alsVariante 3 erhalten, hat aber bei der Handhabbarkeit beim Modellieren wesentlich schlechter abgeschnitten.Dennoch entschieden sich 30% fur diese Variante. Daraus lasst sich schließen, dass die zeitliche Komponenteeine besondere Rolle spielt. Diese Erkenntnis wird fur die Entwicklung der in diesem Konzept verwendetenVariante von großer Wichtigkeit sein (siehe Abschnitt 5.1).

4.3.2. Fragenblock 2: Hierarchien

In einem zweiten Fragenblock wurden zwei Moglichkeiten zur Verarbeitung von Hierarchien in Swimlane-Diagrammen vorgestellt. Dabei wurde gefragt, ob Hierarchien entweder abgeflacht oder getrennt behandeltwerden sollten. 70% der Befragten waren der Meinung, dass Hierarchien abgeflacht werden sollte, also dassdie Hierarchie auf eine Ebene heruntergebrochen wird. Der Vorteil dieser Abflachung ist, dass Hierarchiennicht gesondert betrachtet werden mussen. Bei tiefen Hierarchien konnte dies aber auch zu sehr großen, teilsunubersichtlichen Darstellungen fuhren.

27


4.3.3. Fragenblock 3: AND-Join-Verknupfung

Ein dritter Fragenblock behandelte eine AND-Join-Verknupfung, wie sie in Abbildung 4.7 dargestellt ist.

Abbildung 4.7.: AND-Join-Verknupfung

Bei dieser Verknupfung muss z.B. innerhalb von Swimlane A uberpruft werden, ob eine Funktion in SwimlaneB ausgefuhrt wurde. Dazu wurden in dieser Befragung zwei Moglichkeiten vorgestellt. Moglichkeit 1 ist inAbbildung 4.8 dargestellt. Bei dieser Moglichkeit wird die Funktion der anderen Swimlane mit ubernommenund mit dem Symbol fur die Organisationseinheit gekennzeichnet. Dadurch fallt eine Inkonsistenz in derDarstellung auf, da so Symbole fur Organisationseinheiten bzw. Informationsobjekte im Swimlane-Diagrammvorkommen, was dem Sinn der Swimlanes widerspricht.

Abbildung 4.8.: Moglichkeit 1

Fur Moglichkeit 2, wie sie in Abbildung 4.9 dargestellt ist, haben sich 70% der Befragten entschieden. Einegenaue Beschreibung dieser Darstellung findet sich in Abschnitt 5.2.3.

Abbildung 4.9.: Moglichkeit 2

28


4.3.4. Fragenblock 4: Datenflusse bei Informationsobjekten

Der letzte Fragenblock behandelte die Darstellung von Swimlane-Diagrammen, welche anhand von Informati-onsobjekten aufgebaut werden. Dabei ging es um die Frage, wie die Datenflusse von einem Informationsobjektzu einer Funktion bzw. andersherum dargestellt werden konnten.

Abbildung 4.10 zeigt links eine Ereignisgesteuerte Prozesskette mit Informationsobjekten in der klassischenDarstellung und rechts eine zugehorige Swimlane-Darstellung. Die gegebene EPK steht als Beispiel fur einenProzess, in dem Datenbanktabellen von einer in eine andere Datenbank kopiert werden sollen.

Abbildung 4.10.: EPK (links) und Swimlane-Diagramm (rechts)

Eine Moglichkeit zur Notation des Datenflusses ist, ihn als Text in die Beschriftung der Funktion einzufugen.In einer weiteren Moglichkeit wurde ein Textlabel neben der Funktion platziert (siehe Swimlane DB 2).

Fur die dritte gegebene Moglichkeit entschieden sich 80% der Befragten. Dabei handelt es sich um eineVariante, in der Pfeile mit der Flussrichtung als Aufschrift zur Funktion, bzw. von der Funktion weg zei-gen (siehe Swimlane DB 1). Diese Variante wird schlussendlich auch in der in Abschnitt 5.3 vorgestelltenTransformation von EPK-Diagrammen anhand von Informationsobjekten verwendet.


Das vorangegangenen Kapitel fuhrte in das zu erarbeitende Konzept. Dazu stellte es den Nutzen fur Be-trachter und Modellierer von Ereignisgesteuerten Prozessketten heraus. Im Anschluss wurde eine empirischeBefragung vorgestellt. Dabei wurden die Fragen detailliert beschrieben und die Ergebnisse erlautert.

29

5. Darstellung von Swimlanes in Ereignisgesteuerten Prozessketten

5. Darstellung von Swimlanes in

Ereignisgesteuerten Prozessketten

Nun sollen Regeln und Algorithmen vorgestellt werden, mit denen Ereignisgesteuerte Prozessketten alsSwimlane-Diagramme dargestellt werden konnen. Zunachst wird aber die Darstellungsvariante vorgestellt,die fur diese Regeln und Algorithmen als Grundlage dient.

5.1. Verwendete Variante

Die Ergebnisse der empirischen Untersuchung haben gezeigt, dass Variante 3 und 4 (Abschnitt 4.3.1) einegroße Akzeptanz gefunden haben. Aus diesem Grund und durch die semantischen Unklarheiten von Variante1 wird daher Variante 3 als Basis fur die hier beschriebene Swimlane-Darstellung genommen.

Abbildung 5.1.: Verwendete Variante

Um die zeitliche Komponente und die Einhaltung der Syntax zu gewahrleisten, werden die Ereignisse, welchezur gleichen Zeit auftreten - also z.B. gleiche Ereignisse, die in mehreren Swimlanes vorkommen -, mit einerKante verbunden. Abbildung 5.1 soll dieses Vorgehen verdeutlichen.

30


5.2. Regeln

An dieser Stelle sollen nun einige Regeln aufgestellt werden, welche dann spater in den Algorithmen zumAufbau von Swimlanes angewandt werden.

Im Folgenden werden solche Swimlane-Diagramme, die nach Organisationseinheiten aufgebaut sind, alsOrganisations-Swimlane-Diagramme (kurz: OSD) bezeichnet. Hingegen werden Swimlane-Diagramme, dienach Informationsobjekten aufgebaut sind, Informations-Swimlane-Diagramme (kurz: ISD) genannt.

5.2.1. Grundlegende Regeln

• Anwendungen bzw. unterstutzende Systeme werden als Organisationseinheiten betrachtet.

• Jeder Organisationseinheit (in Organisations-Swimlane-Diagrammen) bzw. jedem Informationsobjekt(in Informations-Swimlane-Diagrammen) wird eine Swimlane zugeordnet.

• Gibt es in OSDs Funktionen, bei denen keine Organisationseinheit angegeben ist, existiert eine Swim-lane mit dem Namen ”undefiniert“, zu welcher diese Funktionen zugeordnet werden.

• Gibt es in ISDs Funktionen, bei denen kein Informationsobjekt angegeben ist, existiert eine Swimlanemit dem Namen ”unabhangig“, zu welcher diese Funktionen zugeordnet werden.

• In OSDs bleiben Symbole fur Informationsobjekte erhalten.

• In ISDs bleiben Symbole fur Organisationseinheiten erhalten.

• In ISDs werden die Richtungen der Datenflusse mittels Pfeilen fur Input und Output gekennzeichnet.

5.2.2. Einfache Transformationsschritte

Nun sollen einfache Transformationsschritte beschrieben werden.

Funktion mit einer Organisationseinheit bzw. einem Informationsobjekt

Ist an einer Funktion nur eine Organisationseinheit bzw. ein Informationsobjekt beteiligt, so wird diese Funk-tion mit ihrem Vorganger- und Nachfolgerereignis in die jeweilige Swimlane verschoben. Diesen Sachverhaltzeigt Abbildung 5.2.

Abbildung 5.2.: Funktion mit einer Organisationseinheit

31


Funktion mit mehreren Organisationseinheiten

Abbildung 5.3 zeigt das Vorgehen bei Funktion mit mehreren Organisationseinheiten. Da mehrere Organisa-tionseinheiten an einer Funktion bedeutet, dass sie parallel an einer Aufgabe arbeiten, wird die dargestellteProzesskette in eine AND-Verknupfung uberfuhrt. Nach dieser Transformation kann dann mit den in Ab-schnitt 5.2.3 vorgestellten Verknupfungen fortgefahren werden.

Abbildung 5.3.: Funktion mit mehreren Organisationseinheiten

Funktion mit mehreren Informationsobjekten

Da Informationsobjekte selbst keine aktiven Elemente sind, also nicht an einer Funktion teilnehmen, mussbei ihnen nicht darauf geachtet werden, ob ein anderes Informationsobjekt vorhanden ist. Daher wird hierdie Verknupfnung, wie in Abbildung 5.4 dargestellt, unverandert in die Swimlanes ubernommen.

Abbildung 5.4.: Funktion mit mehreren Informationsobjekten

5.2.3. Verknupfungen

Verknupfungen haben eine besondere Stellung, da sie semantisch sehr machtig sind. Aus diesem Grund sollennun alle, in einer Ereignisgesteuerten Prozesskette moglichen, Verknupfungen betrachtet werden. Dabei sollenvier Verknupfungen gesondert betrachtet werden.

Ereignis –> Funktion AND-Split

Bei dieser Verknupfung wird im Falle von verschiedenen Organisationseinheiten bzw. Informationsobjektendie AND-Verknupfung aufgelost und auf die jeweiligen Swimlanes verteilt. Dies kann geschehen, da beide

32


Funktionen ausgefuhrt werden mussen. Daher ist es an dieser Stelle fur den Betrachter irrelevant, ob undwie der andere Teilnehmer reagiert. Ist nur eine Organisationseinheit bzw. ein Informationsobjekt beteiligt,so kann diese Verknupfung exakt in die jeweilige Swimlane ubernommen werden.

Abbildung 5.5.: Ereignis –> Funktion AND-Split

Funktion –> Ereignis AND-Join

Wenn an dieser AND-Verknupfung in einem Organisations-Swimlane-Diagramm mehrere Organisationsein-heiten beteiligt sind, so muss in jeder beteiligten Swimlane uberpruft werden, ob der bzw. die anderenBeteiligten ihre Aufgaben ausgefuhrt haben. Aus diesem Grund wird die Verknupfung wie folgt transfor-miert. Diese Transformation ist in Abbildung 5.6 dargestellt.

Angenommen an dieser Verknupfung sind die Organisationseinheiten A und B beteiligt. So wird in derSwimlane A ein Ereignis eingefuhrt, das bestatigt, dass die vorhergehende Funktion bei A ausgefuhrt wurde.Dieses Ereignis wird mit dem Aquivalent der Swimlane B AND-verknupft.

Zur Einhaltung der Syntax muss eine neue Funktion eingefuhrt werden. Diese Funktion ist dann eine Dummy-Funktion, das heißt in ihr wird nichts ausgefuhrt, sie stellt lediglich einen Wartezustand dar. Daher erhalt siedie Aufschrift ”wait for completion“. Auf diese Funktion folgt dann das Ereignis, das auf die ursprunglicheAND-Verknupfung folgte.

Abbildung 5.6.: Funktion –> Ereignis AND-Join (OSD)

Wenn an dieser AND-Verknupfung in einem Informations-Swimlane-Diagramm mehrere Informationsobjektebeteiligt sind (siehe Abbildung 5.7), so wird diese Verknupfung getrennt und in die jeweiligen Swimlanes

33


verteilt. Da Informationsobjekte keine aktiven Elemente sind, sie also nicht selber den Erfolg der Funktionbestimmen konnen, ist hier keine weitere Behandlung notwendig.

Abbildung 5.7.: Funktion –> Ereignis AND-Join (ISD)

Ist an der ursprunglichen AND-Verknupfung nur eine Organisationseinheit bzw. ein Informationsobjektbeteiligt, so wird auch diese exakt in die jeweilige Swimlane ubernommen.

Funktion –> Ereignis OR-Join

Bei dieser Art von Verknupfung wird die OR-Verknupfung wie im Funktion–>Ereignis AND-Join behandelt(siehe Abbildung 5.8). Da das folgende Ereignis eintritt wenn entweder eine oder alle Funktionen ausgefuhrtworden sind, kann es zu semantischen Problemen kommen. So ware es zum Beispiel moglich, dass die folgendeFunktion mehrfach ausgefuhrt wird, wenn die auslosenden Ereignisse zeitversetzt eintreten.

Abbildung 5.8.: Funktion –> Ereignis OR-Join

Abbildung 5.9.: Funktion –> Ereignis OR-Join (ISD)

34


Wie auch beim Funktion–>Ereignis AND-Join, konnen solche Verknupfungen in Informations-Swimlane-Diagrammen aufgespaltet und auf die Swimlanes verteilt werden. Ist an dem OR-Join nur eine Organisa-tionseinheit bzw. ein Informationsobjekt beteiligt, so kann er ohne weitere Behandlung in die Swimlaneubernommen werden.

Funktion –> Ereignis XOR-Join

Bei dieser Verknupfung wird auch ahnlich dem Funktion–>Ereignis AND-Join vorgegangen. Dabei wird dannanstelle einer AND-Verknupfung eine XOR-Verknupfung eingefuhrt. Der Fall von mehreren Organisations-einheit in einem Organisations-Swimlane-Diagramm wird in Abbildung 5.10 dargestellt.

Dabei muss bei dieser XOR-Verknupfung gepruft werden, ob die anderen Teilnehmer ihre Funktion nichtausgefuhrt haben. Auch hier gilt, dass eine Dummy-Funktion eingefuhrt werden muss. Auf diese folgt danndas ursprungliche Ereignis.

Abbildung 5.10.: Funktion –> Ereignis XOR-Join (OSD)

Tritt solch eine XOR-Verknupfung in Informations-Swimlane-Diagrammen auf, so wird sie aufgeteilt und indie jeweiligen Swimlanes verschoben (siehe Abbildung 5.11).

Abbildung 5.11.: Funktion –> Ereignis XOR-Join (ISD)

Ist lediglich eine Organisationseinheit in OSDs bzw. ein Informationsobjekt in ISDs am dem Join beteiligt,wird dieser ohne Anderung in die jeweilige Swimlane ubertragen.

35


weitere Verknupfungen

Da an den weiteren Verknupfungen, wie sie in Tabelle 5.1 dargestellt sind, immer nur eine Funktion beteiligtist, konnen diese direkt in die jeweiligen Swimlanes ubertragen werden.

Ereignis –> Funktion Funktion –> Ereignis

AND-Join AND-Split

OR-Join OR-Split

XOR-Join XOR-Split

Tabelle 5.1.: weitere Verknupfungen

5.3. Vorgehen

Nun werden Vorgehensweisen vorgestellt, mit Hilfe derer vorhandene Ereignisgesteuerte Prozessketten alsSwimlane-Diagramme dargestellt werden konnen. Im Anschluss wird gezeigt, wie neue EreignisgesteuerteProzessketten in Swimlanes aufgebaut werden.

Transformation von vorhandenen EPKs in Organisations-Swimlane-Diagramme

Im Folgenden wird davon ausgegangen, dass eine fertig modellierte Ereignisgesteuerte Prozesskette vorhan-den ist, welche in ein Organisations-Swimlane-Diagramm transformiert werden soll. Das Vorgehen beimErstellen von neuen EPKs wird in einem spateren Abschnitt beschrieben.

Zu Beginn wird fur jede Organisationseinheit eine Swimlane angelegt. Existieren Funktionen, denen kei-

36


ne Organisationseinheit zugeordnet ist, wird eine zusatzliche Swimlane mit dem Titel ”undefiniert“ erstellt.Mit Hilfe dieser Swimlane kann uberpruft werden, ob die EPKs semantisch korrekt sind. In der fertigenSwimlane-Darstellung sollte keine Swimlane ”undefiniert“ mehr existieren, da einer Funktion semantisch im-mer mindestens eine Organisationseinheit oder ein IT-System zugeordnet ist.

Wurden die Swimlanes angelegt, so kann begonnen werden die Elemente in die jeweiligen Swimlanes zuverschieben. Dazu werden alle Funktionen in die Swimlane zu ihrer Organisationseinheit verschoben bzw. -im Falle von mehreren teilnehmenden Organisationseinheiten - kopiert. Ist an einer Funktion keine Organi-sationseinheit angegeben, so wird diese in der Swimlane ”undefiniert“ abgelegt. Zu diesen Funktionen werdendann die anderen zugehorigen Elemente anhand der Regeln aus Abschnitt 5.2 hinzugefugt.

Die Symbole fur Organisationseinheiten entfallen in der Swimlane-Darstellung komplett. Symbole fur In-formationsobjekte bleiben allerdings weiterhin erhalten. Da die vertikale Achse der Swimlane die Zeit repra-sentiert, werden alle Elemente, die gleich sind, und jene, die zur gleichen Zeit stattfinden, auf der gleichengedachten horizontalen Linie gezeichnet. Ereignisse, auf die dies zutrifft, werden zusatzlich mit Linien ver-bunden. Dieses sind die einzigen Linien in EPK-Swimlane-Diagrammen, die die Grenzen einer Swimlaneuberschneiden konnen.

Transformation von vorhandenen EPKs in Informations-Swimlane-Diagramme

Nun soll das Vorgehen beim Transformieren in ein Informations-Swimlane-Diagramm beschrieben werden.Allgemein verfahrt man bei dieser Transformation wie bei Organisations-Swimlane-Diagrammen. Anstatt derOrganisationseinheiten werden hier die Informationsobjekte betrachtet. So wird fur Funktionen, an denenkein Informationsobjekt beteiligt ist, keine Swimlane ”undefiniert“ erstellt, sondern eine Swimlane ”unab-hangig“. In der Semantik von Ereignisgesteuerten Prozessketten mussen an Funktionen nicht zwangslaufigInformationsobjekte beteiligt sein. Diese Swimlane kann auch in fertigen ISDs erhalten bleiben. Wichtig beidieser Darstellung ist, dass hier teilsweise andere Regeln gelten, als bei OSDs.

Die Symbole fur Informationsobjekte entfallen in dieser Darstellung. Symbole fur Organisationseinheitenbleiben jedoch erhalten. Um den Datenfluss der Informationsobjekte zu kennzeichnen, werden Pfeile zu bzw.von den Funktionen weg eingezeichnet gezeichnet. Diese Pfeile werden zusatzlich mit einer Aufschrift furInput und Output versehen. Ist ein Informationsobjekt ein Input fur die Funktion, so zeigt der Pfeil zurFunktion hin. Ist es hingegen ein Output, so zeigt der Pfeil von der Funktion weg. Ist das Informationobjektsowohl Input als auch Output, so zeigt der Pfeil in beide Richtungen. Desweiteren werden alle Ereignisse,die zur gleichen Zeit stattfinden, mit Linien verbunden.

Erstellen von EPKs in Swimlane-Diagrammen

Will man Ereignisgesteuerte Prozessketten in einer Swimlane-Darstellung aufstellen, so hat man zwei Mog-lichkeiten. Entweder man baut sie in der klassischen Darstellung auf und geht dann mit den oben beschriebenMethoden vor oder man stellt die EPKs direkt in Swimlanes dar.

Dazu beginnt man zeitlich mit der ersten Funktion und legt fur die an dieser Funktion beteiligten Or-ganisationseinheiten bzw. Informationsobjekte Swimlanes an. In diese Swimlanes wird die Funktion und dasvorhergehende Ereignis und evtl. der vorhergehende Prozesswegweiser in die neu angelegten Swimlanes ge-zeichnet.

Nun kann nach den oben vorgestellten Regeln fortgefahren werden. Dabei ist wichtig, dass fur jede neuhinzukommende Organisationseinheit bzw. jedes Informationsobjekt eine neue Swimlane erstellt wird.

37


5.4. Beispiel-Transformation

Nun wird eine Beispiel-EPK vorgestellt, die mit den in den letzten Abschnitten vorgestellten Regeln undVorgehensweisen in ein Swimlane-Diagramm transformiert wird. Diese Ereignisgesteuerte Prozesskette be-schreibt die allabendliche Kassenabrechnung eines Supermarktes (siehe Abbildung 5.12). Dabei sind die dreiOrganisationseinheiten Kassiererin, Hauptkassiererin und Marktleiter, sowie die Anwendung Kassensystembeteiligt.

Abbildung 5.12.: Beispiel einer manuellen Transformation: EPK in klassischer Darstellung

38


Schritt 1

Abbildung 5.13.: Beispiel einer manuellen Transformation (Schritt 1)

Funktionen mit mehreren Organisationseinheiten werden aufteilen.

39


Schritt 2


Fur jede Organisationseinheit wird eine Swimlane angelegt. Daraufhin werden die Funktionen mitVorganger- und Nachfolgerereignissen und eventuellen Verknupfungen auf die jeweilige Swimlanes verteilt.

40


Schritt 3


Die Verknupfungen werden nach den in Abschnitt 5.2.3 dargestellten Regeln behandelt.

41


Schritt 4


Im letzten Schritt werden gleiche Ereignisse mit einer Linie verbunden.

42



In diesem Kapitel wurde zu Beginn die endgultig verwendete Variante einer Swimlane-Darstellung beschrie-ben. Im Folgenden wurden Regeln zur Transformation von EPKs in ein Swimlane-Diagramm aufgestellt.Diese Regeln wurden dann in den vorgestellten Vorgehensweisen angewendet. Daraufhin wurde das Vorge-hen anhand einer Beispiel-Transformation praktisch gezeigt.

43

6. Implementierung

6. Implementierung

In diesem Kapitel soll nun die Implementierung einer Visualisierung von Swimlanes in EreignisgesteuertenProzessketten beschrieben werden. Zu diesem Zweck wurde ein Plug-In mit dem Namen LaneEPC fur dieEntwicklungsumgebung Eclipse entwickelt. Dieses Plug-In basiert wiederum auf dem vom Fachgebiet Softwa-re Engineering der Leibniz Universitat Hannover zur Verfugung gestellten Plug-In ProFLOW. Im folgendenAbschnitt werden LaneEPC und die zugrundeliegenden Architekturen beschrieben.

6.1. Zugrundeliegende Architekturen

6.1.1. Eclipse und das Graphical Editing Framework (GEF)

Eclipse ist eine Java-basierte Entwicklungsumgebung [Thea]. Durch die Portabilitat von Java ist sie fur vielePlattformen verfugbar. Uber die reine Anwendungsentwicklung hinaus, bietet Eclipse die Moglichkeit Plug-Ins zu entwickeln, wodurch eine Vielzahl von neuen Funktionen der Entwicklungsumgebung hinzugefugtwerden konnen. So ist es zum Beispiel durch das Graphical Editing Framework (GEF) moglich, grafischeEditoren und Views der Workbench hinzuzufugen [Thec]. Damit konnen dann nicht nur Texte bearbeitet,sondern auch Diagramme gezeichnet werden. Beim Schreiben dieser Arbeit lagen sowohl Eclipse als auchGEF in der Version 3.2 vor.

6.1.2. ProFLOW

ProFLOW ist ein Plug-In-Feature fur Eclipse, mit dem Flussdiagramme gezeichnet werden konnen. Dabeistehen in der vorliegenden Version 1.0.1 in Verbindung mit GEF Mechanismen zur Zeichnung von UML-Aktivitatsdiagrammen und erweiterten Ereignisgesteuerten Prozessketten zur Verfugung. Daruber hinausbietet es eine eigene Plug-In-Struktur, die es ermoglicht, mit wenigen Schritten beliebige Prozesstypen hin-zuzufugen. Dazu mussen lediglich fur die einzelnen Elemente des neuen Prozesses die Modellklassen, Objekt-darstellungen, Aktionen, sowie Regeln, die auf diese Elemente angewendet werden, geschrieben werden.

ProFLOW besteht in der vorliegenden Version aus vier Plug-Ins. Dabei ist das Plug-In ProFLOW.coreim MVC-Pattern [Maj04] fur das Model und fur weitere Kernoperationen, wie z.B. Dateizugriffe, zustandig.Hingegen regelt ProFLOW.ui View und Controller. Das Plug-In ProFLOW.activity stellt den Diagramm-typ fur UML-Aktivitatsdiagramme zur Verfugung. Schlussendlich ist dann im Plug-In ProFLOW.eepk allesNotwendige zum Modellieren von Ereignisgesteuerten Prozessketten enthalten.

6.2. LaneEPC

LaneEPC ist nun das in dieser Arbeit entwickelte Plug-In fur Eclipse. Dabei basiert es auf ProFLOW, stelltaber keinen neuen Prozesstyp dar. Vielmehr wird es verwendet, um Ereignisgesteuerte Prozessketten, welchein ProFLOW modelliert worden sind, in Swimlanes darzustellen. Dazu wird der Prozess nach dem Einlesenvon einem Transformator behandelt, der ihn in eine Swimlane-Darstellung umwandelt. Dieser Transformatorwird in Abschnitt 6.3 ausfuhrlich erlautert.

44

6. Implementierung

Zunachst soll aber das Verhaltnis der Plug-Ins zueinander und die Struktur eines Swimlane-Diagrammsin LaneEPC beschrieben werden. Im Anschluss daran wird kurz auf Benutzerinteraktionen eingegangen.

6.2.1. Verhaltnis zwischen den Plug-Ins

Abbildung 6.1.: Das Verhaltnis der Plug-Ins untereinander

Abbildung 6.1 verdeutlicht das Verhaltnis zwischen LaneEPC und den beteiligten ProFLOW-Plug-Ins. EinProFLOW-Prozesstyp-Plug-In, zum Beispiel gegeben durch das Plug-In ProFLOW.eepk, enthalt Model, Viewund Controller aller dazugehorigen Elemente. Dieser Prozesstyp muss in der Form auf der Ereignisgesteu-erten Prozesskette basieren, dass EPK-Elemente, wie Ereignisse und Funktionen, definiert werden. Dabeiverwendet er die jeweiligen Mechanismen aus ProFLOW.core und ProFLOW.ui.

LaneEPC benutzt wiederum die Elemente und Funktionalitaten, die vom Prozesstyp zur Verfugung gestelltwerden. Daruber hinaus werden neue Elemente auf Basis von ProFLOW.core und ProFLOW.ui implemen-tiert, wie zum Beispiel Model und View einer Swimlane oder einer Syncronisationslinie.

6.2.2. Interne Struktur

Abbildung 6.2.: Plug-In-Struktur

45

6. Implementierung

Wie Abbildung 6.2 zeigt, wird beim Start von LaneEPC ein LaneEPCEditor geoffnet. Dieser erhalt einen Pro-zess von dem mit ProFLOW gelieferten XMLImporter. Der XMLImporter liest eine Datei im ProFLOW-Formatein. In dieser Datei ist der Prozesstyp als ID gespeichert. Mittels dieser ID sucht der aus ProFLOW stam-mende ExtensionPointManager das zugehorige Prozessobjekt, in welches die in der Datei enthaltenen Datengespeichert werden. Bis zu diesem Punkt ist der Ablauf in LaneEPC und ProFLOW gleich.

Wurde der Prozess fertig eingelesen, sucht der LaneEPCEditor durch den ExtensionPointManager die fur diesenProzess moglichen Diagrammtypen und bietet diese dem Benutzer als Auswahl an. Mit der Benutzerwahlbekommt der Editor wiederum aus dem ExtensionPointManager das zu diesem Diagrammtyp gehorende Trans-formatorobjekt.

An dieses Transformatorobjekt wird der Prozess ubergeben und umgewandelt. Das Transformatorobjektmuss dabei von der Klasse CommonTransformator abgeleitet sein.

Im Plug-In LaneEPC sind bereits zwei Transformatoren fur Ereignisgesteuerte Prozessketten aus dem Plug-In ProFLOW.eepk enthalten. Dabei implementiert ein Transformator die Transformation von Ereignisge-steuerten Prozessketten in Organisations-Swimlane-Diagramme (EEPKOSDTransformator) und ein weiterer inInformations-Swimlane-Diagramme (EEPKISDTransformator). Auf diese Transformatoren beziehen sich diefolgenden Abschnitte.

Abbildung 6.3.: Metamodell eines Swimlane-Diagramms

Abbildung 6.3 zeigt das Metamodell einer Ereignisgesteuerten Prozesskette aus ProFLOW.eepk in einemSwimlane-Diagramm, wie es von LaneEPC verwendet wird. Der Swimlane-Prozess ist der Prozess, der vonGEF und ProFLOW angezeigt wird. Dieser enthalt mindestens eine Swimlane. Eine Swimlane wiederumenthalt die Verknupfungselemente AND, OR und XOR aus ProFLOW.core und Ereignis- und Funktionsele-mente aus ProFLOW.eepk.

46

6. Implementierung

Funktionen werden in Swimlanes zusatzlich Annotationen angefugt. In Organisations-Swimlane-Diagrammensind dies Input- und Outputobjekte fur Informationsobjekte. Bei Informations-Swimlane-Diagrammen wer-den neben Organisationseinheiten sogenannte ISD-Elemente verwendet. Die ISD-Elemente Input, Outputund In-/Output stellen die Richtungen des Datenflusses dar. Dagegen werden Independent-Objekte an dieFunktion angefugt, die in der ”unabhangig“-Swimlane stehen, da an diesen keine Richtung verzeichnet werdenkann.

6.2.3. Benutzerinteraktion

LaneEPC kann gestartet werden, indem im Package Explorer von Eclipse mit der rechten Maustaste auf einebestehende ProFLOW-Datei geklickt und ”Open with“ und ”LaneEPC“ ausgewahlt wird. Gibt es fur denProzesstyp dieser Datei nur einen Diagrammtyp, so wird dieser geoffnet. Wenn es mehrere Diagrammtypengibt, erscheint ein Auswahlfenster, aus dem der gewunschte Typ ausgewahlt werden kann. Gibt es dagegenkeinen Diagrammtyp, so wird eine Fehlermeldung angezeigt.

Wird ein Organisations-Swimlane-Diagramm fur einen ProFLOW.eepk -Prozess angezeigt, konnen Funktio-nen, die sich in der ”undefiniert“-Swimlane befinden, mit Rechtsklick auf diese und der Auswahl von ”Moveundefined Function“ in eine andere Swimlane verschoben werden. Diese Aktion passt den ursprunglich ein-gelesenen Prozess an, wodurch diese Anderung dann - nach Speicherung - auch in ProFLOW verfugbarsind.

6.3. Transformator

Ein Transformator wandelt einen eingelesenen Prozess in eine Swimlane-Darstellung um und gibt ihn hinter-her an den Editor zuruck der ihn dann anzeigt. Im Folgenden werden die Schritte der in LaneEPC integriertenTransformatoren von ProFLOW.eepk -Prozessen in OSDs und ISDs vorgestellt. Wie Transformatoren fur an-dere Prozess- oder Diagrammtypen implementiert werden konnen, wird in Abschnitt 6.4.1 beschrieben.

• Zuerst werden die Funktionen des eingegebenen Prozesses durchlaufen. Dabei wird nach solchen ge-sucht, die im Falle von Organisations-Swimlane-Diagrammen keine Organisationseinheiten und im Fallevon Informations-Swimlane-Diagrammen keine Informationsobjekte enthalten. Diesen Funktionen wirddann eine Organisationseinheit mit der Bezeichnung ”undefiniert“ bzw. ein Informationsobjekt mit derBezeichnung ”unabhangig“ angehangt.

• Im nachsten Schritt werden alle Funktionen behandelt, an denen mehr als eine Organisationseinheitbzw. ein Informationsobjekt verzeichnet sind. Diese werden dann nach der Regel in Abschnitt 5.2.2aufgesplittet. Der Einfachheit halber wird diese Regel auch bei ISDs angewandt, so mussen mehrereInformationsobjekte spater nicht gesondert behandelt werden.

• Nachdem nun an jeder Funktion in OSDs genau eine Organisationseinheit bzw. in ISDs genau einInformationsobjekt verzeichnet ist, konnen alle Beteiligten gesucht werden. Diese Liste aller Beteiligtenwird nun benutzt, um die jeweiligen Swimlanes anzulegen. Dabei werden die Swimlanes so sortiert, dassdie Swimlane ”undefiniert“ in OSDs ganz links steht und die Swimlane ”unabhangig“ in ISDs ganz rechtssteht. Dies geschieht, damit in OSDs Inkonsistenzen in der Modellierung sofort sichtbar sind, da, wiebereits beschrieben, in OSDs keine Funktionen ohne Organisationseinheiten existieren sollten.

• Im nachsten Schritt werden nun die Elemente auf die zugehorigen Swimlanes verteilt. Dabei wird jedeFunktion einzeln behandelt. Sie und ihre Vorganger- und Nachfolgerereignisse, inklusive eventuellerVerknupfungen, werden in die jeweilige Swimlane geschrieben.

47

6. Implementierung

• Sind nun alle Funktionen verteilt, werden auf die in den Swimlanes vorhandenen Verknupfungen diein Abschnitt 5.2.3 vorgestellten Regeln angewandt.

• Im Anschluss daran werden alle gleichen Ereignisse, die in mehreren Swimlanes vorkommen, mit einersogenannten Syncronisationslinie miteinander verbunden. Enthalten nun alle Swimlanes ihre Elemente,mussen diese noch positioniert werden. Dazu wird erst eine vertikale Positionierung vorgenommen, beiwelcher die Koordinaten der Elemente mit ihren Nachbarswimlanes abgeglichen werden, um die zeitlicheKomponente zu gewahrleisten. Danach wird eine horizontale Positionierung vorgenommen. Dabei wirdfur jede Swimlane versucht, die bestmogliche horizontale Position ihrer Elemente herzustellen.

• Im letzten Schritt werden dann die Maße der Swimlanes angepasst und diese nebeneinander platziert.

• Der so transformierte Prozess wird nun wieder an das Editorfenster ubergeben und von GEF undProFLOW gezeichnet.

6.4. Erweiterungsmoglichkeiten

Das Ziel der Implementierung dieser Bachelorarbeit ist eine Visualisierung von Swimlanes in Ereignisgesteu-erten Prozessketten. Hier sollen nun Erweiterungsmoglichkeiten fur LaneEPC vorgestellt werden, die uberdieses Ziel hinausgehen, aber dennoch in Zukunft interessant sein konnten.

6.4.1. Weitere Diagrammtypen und weitere EPK-basierte Prozesstypen

In letzter Zeit kristallisieren sich immer mehr Prozesstypen heraus, die auf Ereignisgesteuerten Prozessket-ten basieren. Als Beispiel dafur kann man die in der Masterarbeit von Sebastian Intas [Int06] vorgestellteEreignisgesteuerte Prozesskette fur Webservices nennen.

LaneEPC bietet zu diesem Zweck die Moglichkeit, Plug-Ins zu schreiben, die neue Diagrammtypen defi-nieren. Dazu muss in diesem lediglich eine Extension auf LaneEPC.diagram erstellt werden. In dieser werdendie folgenden Werte angegeben:

• processId - Die Typ-ID des Prozesses, der transformiert werden soll.

• id - Die ID des Diagramm-Typs

• name - Der Name des Diagramm-Typs. (Wird bei der Auswahl der Diagramm-Typen angezeigt.)

• class - Die Transformator-Klasse des Diagramm-Typs (erweitert CommonTransformator).

• undefinedName - Der Name der Swimlane, in die nicht zugewiesene Elemente eingefugt werden.

• undefinedClass - Die Klasse der Annotation, mit welcher undefinedName angefugt wird.

Desweiteren muss ein Transformator - als Singleton-Klasse - geschrieben werden, der CommonTransformator

erweitert. In diesem werden Funktionen zur Verarbeitung von Verknupfungen (handleConnectors()), zur Sor-tierung der Swimlanes bzw. Liste der Beteiligten (sortListOfParticipants()), falls notwendig zum Ersetzenvon Annotationen (replaceAnnotation())und folgende Getter und Funktionen zum Validieren und Erstellenvon Elementen implementiert:

• getDiagramId() - Gibt die ID des Diagrammtypes zuruck.

• getTransitionType() - Gibt den Transitionstyp zuruck.

• isValidFunction(Element element) - Uberpruft, ob element eine Funktion ist.

48

6. Implementierung

• isValidEvent(Element element) - Uberpruft, ob element ein Ereignis ist.

• isValidConnector(Element element) - Uberpruft, ob element eine Verknupfung ist.

• isValidAnnotation(Annotation annotation) - Uberpruft, ob annotation eine Annotation ist, nach derdie Swimlanes aufgebaut werden.

• createNewEvent(String name) - Erstellt ein neues Ereignis mit Namen name.

• createNewFunction(String name) - Erstellt eine neue Funktion mit Namen name.

• createNewANDConnector() - Erstellt eine neue AND-Verknupfung. (Benotigt fur die Aufsplittung vonmehreren Annotationen an einer Funktion.

• createNewProcess() - Erstellt einen neuen Prozess().

In den zuletzt genannten Funktionen werden die durch den Prozesstyp gegeben Elemente eingetragen.

Desweiteren wird die Moglichkeit gegeben, uber den Extension Point LaneEPC.action Aktionen zu definieren,die speziell auf einen Diagrammtyp angewendet werden konnen. So konnen die Aktionen, wie in ProFLOWublich, uber ProFLOW.ui.processActions und ProFLOW.ui.modelObjectActions oder LaneEPC.action, unter derAngabe eines Diagrammtyps, eingetragen werden.

6.4.2. Editorenfenster

In Eclipse gibt es die Moglichkeit, Editorenfenster mit mehreren Arbeitsflachen zu offnen. Zwischen diesenArbeitsflachen kann dann mittels Registerkarten gewechselt werden. So konnte man sich vorstellen, dass,wenn eine ProFLOW-Datei geoffnet wird, auf einer Registerkarte der Standard-ProFLOW-Editor und aufweiteren Registerkarten die Darstellungen fur die Diagrammtypen, die fur diesen Prozess verfugbar sind,angezeigt wird. Um dies zu realisieren, muss die Editor-Klasse in ProFLOW.ui angepasst, bzw. ersetztwerden. Weitere Informationen hierzu finden sich in der API von Eclipse [Theb].

6.4.3. Verschiebung und Skalierung von Elementen

ProFLOW unterstutzt in der vorliegenden Version keine Containerelemente, welche allerdings fur die Swim-lanes zwingend notwendig sind. Containerelemente sind Elemente, die andere Elemente beinhalten konnen.Die Swimlanes wurden hier provisorisch als Containerelemente implementiert.

Allerdings sind im Moment noch keine Benutzerinteraktionen moglich, die sich auf das Verschieben undSkalieren von Elementen innerhalb einer Swimlane beziehen. Aus diesem Grund wurde eine automatischePositionierung der Elemente implementiert.

Dies kann aber keine endgultige Losung sein, da ein Benutzer in vielen Fallen sein Diagramm von Hand anpas-sen mochte. Dies sollte dann mit kleinen Anpassungen moglich sein, wenn Containerelemente in ProFLOWfertiggestellt sind. Dazu mussen lediglich die EditPolicies fur die Swimlane-Elemente eingerichtet werden.

6.4.4. EPK-Elemente

ProFLOW.eepk unterstutzt aktuell nicht alle Elemente einer Ereignisgesteuerten Prozesskette. So sind imMoment noch keine Prozesswegweiser und keine Anwendungssysteme implementiert. Wenn diese fertigge-stellt sind, mussen in den jeweiligen Transformatoren nur die beiden Funktionen isValidAnnotation() undisValidEvent() angepasst werden.

49

6. Implementierung

6.4.5. EPML

In Abschnitt 2.5 wurde der XML-Dialekt EPML vorgestellt. Man konnte sich nun gut vorstellen, EPML alsalternative Dateiquelle fur Ereignisgesteuerte Prozessketten zu verwenden. Dazu wurde, parallel zu dem inProFLOW integrierten XMLImporter, ein EPML-Importer implementiert werden, der EPML-Dateien ausliestund daraus Prozesse erstellt. EPML und das ProFlow-Dateiformat sind sich sehr ahnlich, daher sollten keineumfangreichen Anderungen gegenuber dem XMLImporter vorgenommen werden mussen. Durch das EPML-Format waren auch Hierarchien in Ereignisgesteuerten Prozessketten (siehe Abschnitt 2.2.2) moglich.


In diesem Kapitel wurde die Implementierung einer Visualisierung von Swimlanes in EreignisgesteuertenProzessketten vorgestellt. Dazu wurden die zugrundeliegenden Architekturen beschrieben. Darauf folgendwurde LaneEPC erlautert. Es wurde das Verhaltnis zu den ProFLOW-Plug-Ins dargestellt und auf dieinterne Struktur von LaneEPC, sowie die Benutzerinteraktionen eingegangen. Im Anschluss wurden dieTransformatoren fur ProFLOW.eepk vorgestellt. Zum Ende dieses Kapitels wurden dann ausfuhrlich diverseErweiterungsmoglichkeiten beschrieben.

50

7. Beispiel

7. Beispiel

In diesem Kapitel werden zwei Beispiele fur Swimlane-Diagramme in ProFLOW gegeben. Dazu wird jeweilszuerst die Darstellung in ProFLOW und danach in LaneEPC gezeigt. Die Ereignisgesteuerte Prozesskettewelche hier als Organisations-Swimlane-Diagramm dargestellt ist, handelt von der Leergutannahme in einemSupermarkt mit den Beteiligten Kunde und Mitarbeiter. Das Beispiel fur Informations-Swimlane-Diagrammezeigt wiederum das aus Abschnitt 4.3.4 bekannte Beispiel eines Kopiervorgangs von Datenbanktabellen.

51

7. Beispiel

7.1. Organisations-Swimlane-Diagramm

Beispiel OSD - ProFLOW

Abbildung 7.1.: Beispiel fur OSD: EPK in ProFLOW

52

7. Beispiel

Beispiel OSD - LaneEPC

Abbildung 7.2.: Beispiel fur OSD: EPK in LaneEPC

53

7. Beispiel

7.2. Informations-Swimlane-Diagramm

Beispiel ISD - ProFLOW

Abbildung 7.3.: Beispiel fur ISD: EPK in ProFLOW

54

7. Beispiel

Beispiel ISD - LaneEPC

Abbildung 7.4.: Beispiel fur ISD: EPK in LaneEPC

55

8. Zusammenfassung und Ausblick


Ziel dieser Arbeit war es, den aus UML und BPML bekannten Begriff der Swimlanes auf EreignisgesteuerteProzessketten zu ubertragen. Dazu sollte ein Konzept aufgestellt werden, mit dem es moglich ist, Ereignisge-steuerte Prozessketten aus der klassischen Darstellung in eine Swimlane-Darstellung zu transformieren. DieResultate dieses Konzepts sollten zur Visualisierung in einem Plug-In fur die Entwicklungsumgebung Eclipserealisiert werden.

Das zweite Kapitel erlauterte dazu alle, fur das Konzept notigen, Grundlagen. Es wurden Geschaftspro-zesse in Verbindung mit serviceorientierten Architekturen gebracht, worauf sich dann die Notwendigkeit furdie Ereignisgesteuerte Prozesskette begrundete. Diese wurde mit ihren Elementen vorgestellt. Der folgendeAbschnitt fuhrte in die Idee, die hinter Swimlanes steht, ein und visualisierte sie an einem Beispiel in UML-Aktivitatsdiagrammen. Nun galt es, das XML-Schema der Event-Driven-Process-Chain-Markup-Language(EPML) vorzustellen, welche langsam zum Standard-Austauschformat fur Ereignisgesteuerte Prozesskettenwird.

Kapitel 3 beschaftigte sich mit einer Gegenuberstellung von Ereignisgesteuerten Prozessketten und UML-Aktivitatsdiagrammen. Dazu wurde UML kurz vorgestellt, worauf im Anschluss UML-Aktivitatsdiagrammemit der Ereignisgesteuerten Prozesskette verglichen worden sind.

Im vierten Kapitel wurde dann in das auszuarbeitende Konzept eingefuhrt. Dabei wurde der Nutzen vonSwimlanes herausgestellt. Anhand einer empirischen Befragung wurden im Folgenden erste Anregungen zumKonzept validiert. Hierzu stellte es den verwendeten Fragebogen ausfuhrlich vor.

Das 5. Kapitel beschaftigte sich mit Regeln und Vorgehensweisen zum Transformieren von Ereignisgesteuer-ten Prozessketten in eine Swimlane-Darstellung. Eine Beispieltransformation zeigte dann am Ende, wie dieseTransformation Schritt fur Schritt ablauft.

Kapitel 6 stellte die Implementierung einer Visualisierung von Swimlanes in Ereignisgesteuerten Prozess-ketten vor. Dazu wurden die grundlegenden Architekturen beschrieben und mit einer Beschreibung desentwickelten Plug-Ins LaneEPC verknupft. Dazu wurde der Transformator vorgestellt, der die EPK in einSwimlane-Diagramm umwandelt. Den Abschluss dieses Kapitels machte dann eine Beschreibung, wie La-neEPC erweitert werden konnte.

Nachdem in Kapitel 6 die Implementierung dargestellt wurde, wurden in Kapitel 7 jeweils ein Beispiel furein Organisations-Swimlane-Diagramm und ein Informations-Swimlane-Diagramm in LaneEPC vorgestellt.

Als Fazit fur diese Arbeit lasst sich sagen, dass das Konzept die geforderten Ziele erfullt. Es wurden Regelnzur Transformation von Ereignisgesteuerten Prozessketten in eine Swimlane-Darstellung aufgestellt und derNutzen dafur erlautert. Insgesamt kann man sagen, dass Swimlanes in Ereignisgesteuerten Prozessketteneine erhebliche Erleichterung, insbesondere fur den Betrachter, darstellen.

56


Je nach Komplexitat des Prozesses konnen aber durchaus große Diagramme entstehen. Werden relativ kleineProzesse mit wenigen beteiligten Organisationseinheiten oder Informationsobjekten verwendet, ist zu erwa-gen, ob die klassische Darstellung nicht die bessere Wahl ware. Sind allerdings viele Organisationseinheitenbzw. Informationsobjekte in einem Prozess beteiligt, so sollte die Swimlane-Darstellung bevorzugt werden.

8.1. Ausblick

Es gibt mittlerweile viele Konzepte, die sich mit der Erweiterung von Ereignisgesteuerten Prozessketten be-fassen, um sie fur spezielle Anwendungsfalle anzupassen. So zum Beispiel werden haufig Attribute den Funk-tionen einer EPK hinzugefugt. Nun kann man sich vorstellen, dass diese Attribute auch in einer Swimlane-Darstellung verarbeitet werden. Wird etwa als Attribut der Ort der Ausfuhrung einer Funktion angegeben, sokonnten diese Orte, wie die beschriebenen Organisations- und Informations-Swimlane-Diagramme, in Orts-Swimlane-Diagrammen dargestellt werden.

In [GRvdA05] stellt der Autor Erweiterungen an den Verbindungen von Funktionen zu ihren Annotatio-nen aus. Damit bedeuten mehrere Organisationseinheiten an einer Funktion nicht zwangslaufig, dass dieseparallel an einer Aufgabe arbeiten. Es bietet vielmehr eine Unterscheidung zwischen paralleler, sequentieller,gemeinsamer und alternativer Bearbeitung einer Funktion. Fur diese Anderungen konnten neue Regeln zurTransformation aufgestellt werden.

Desweiteren werden in [FL02] Refactoring-Mechanismen fur Ereignisgesteuerte Prozessketten vorgestellt,wobei neue Verknupfungen eingefuhrt werden. Fur diese Verknupfungen wurden auch neue Regeln gelten.Die Bedingungen, die mit diesen Verknupfungen verbunden sind, werden hier in Matrizen abgepruft. Eskonnte somit ein Konzept ausgearbeitet werden, dass diese Bedingungen automatisiert oder teilautomati-siert verarbeit und anhand dessen Regeln zur Darstellung in einem Swimlane-Diagramm aufgestellt werden.

57

Literaturverzeichnis


[BDFK03] Becker, Jorg, Patrick Delfmann, Thorsten Falk und Ralf Knackstedt: Multiper-spektivische ereignisgesteuerte Prozessketten. In: Nuttgens, Markus und Frank J. Rump

(Hrsg): EPK 2003 - Geschaftsprozessmanagement mit Ereignisgesteuerten Prozessketten, Pro-ceedings des GI-Workshops und Arbeitskreistreffens, S. 45–60, Bamberg, Oktober 2003.

[Boo01] Booker, Glenn: Process Definition Overview. In: CSC Papers competition 2002, Philadelphia,August 2001. Computer Sciences Corporation. Verfugbar unter: http://www.pages.drexel.edu/~grb25/pubs.html.

[BRJ99] Booch, Grady, Jim Rumbaugh und Ivar Jacobson: Das UML-Benutzerhandbuch. Profes-sionelle Softwareentwicklung. Addison Wesley Longman Verlag GmbH, Munchen, 1999.

[Dan99] Dandl, Jorg: Objektorientierte Prozeßmodellierung mit der UML und EPK. In: Schwickert,

Axel C. (Hrsg): Arbeitspapiere WI, Nummer 12, Lehrstuhl fur Allg. BWL und Wirtschaftsin-formatik, Universitat Mainz, 1999.

[FL02] Fettke, Peter und Peter Loos: Refactoring von Ereignisgesteuerten Prozessketten. In:Nuttgens, Markus und Frank J. Rump (Hrsg): EPK 2002 - Geschaftsprozessmanagementmit Ereignisgesteuerten Prozessketten, Proceedings des GI-Workshops und Arbeitskreistreffens,Trier, November 2002.

[FvL03] Frank, U. und B. L. van Laak: Anforderungen an Sprachen zur Modellierung von Ge-schaftsprozessen. In: Arbeitsberichte des Instituts fur Wirtschaftsinformatik, Band 34, Januar2003. Arbeitsberichte des Instituts fur Wirtschaftsinformatik.

[Ged] Gedilan Consulting GmbH: Nautilus - Prozessmanagment. Verfugbar unter: http://www.gedilan.com/prozessmanagement_software/index.php.

[GRvdA05] Gottschalk, Florian, Michael Rosemann und Wil M.P. van der Aalst: My own pro-cess: Providing dedicated views on EPCs. In: Nuttgens, Markus und Frank J. Rump (Hrsg):EPK 2005 - Geschaftsprozessmanagement mit Ereignisgesteuerten Prozessketten, Proceedingsdes GI-Workshops und Arbeitskreistreffens, Hamburg, Dezember 2005.

[Int06] Intas, Sebastian: Konzept fur die Einbindung von Webservices in Ereignisgesteuerte Prozess-ketten. Masterarbeit, Fachgebiet Software Engineering, Leibniz Universitat Hannover, Hannover,Juli 2006.

[Jec] Jeckle, Mario: UML auf gut Deutsch. Verfugbar unter: http://www.jeckle.de/uml.de.

[KNS92] Keller, Gerhard, Markus Nuttgens und August-Wilhelm Scheer: Semantische Pro-zessmodellierung auf der Grundlage “Ereignisgesteuerter Prozessketten (EPK)”. In: Scheer,

A.-W. (Hrsg): Veroffentlichungen des Instituts fur Wirtschaftsinformatik (IWi), Universitatdes Saarlandes, Heft 89, Saarbrucken, 1992.

[Lar] Larsson, Alexander: Dia Diagrammeditor. Verfugbar unter: http://live.gnome.org/Dia.

58

http://www.pages.drexel.edu/~grb25/pubs.html

http://www.pages.drexel.edu/~grb25/pubs.html

http://www.gedilan.com/prozessmanagement_software/index.php

http://www.gedilan.com/prozessmanagement_software/index.php

http://www.jeckle.de/uml.de

http://live.gnome.org/Dia


[LGS05] Lubke, Daniel, Jorge Marx Gomez und Kurt Schneider: Serviceorientierte Architekturenund Prozessmanagement. Nummer 3/2005 in ERP Management. GITO Verlag mbH, 2005.

[Lub06] Lubke, Daniel: Transformation of Use Cases to EPC Models. In: Nuttgens, Markus,Frank J. Rump und Jan Mendling (Hrsg): EPK 2006 - Geschaftsprozessmanagement mitEreignisgesteuerten Prozessketten, Proceedings des GI-Workshops und Arbeitskreistreffens, S.137–156, Wien, Dezember 2006.

[Maj04] Majewski, Bo: A Shape Diagram Editor, Dezember 2004. Verfugbar unter: http://www.

eclipse.org/articles/Article-GEF-diagram-editor/shape.html.

[Mic] Microsoft Corporation: Microsoft Visio. Verfugbar unter: http://office.microsoft.

com/de-de/visio/default.aspx.

[MN03] Mendling, Jan und Markus Nuttgens: Konzeption eines XML-basierten Austauschforma-tes fur Ereignisgesteuerte Prozessketten (EPK). In: Informationssystem Architekturen, Wirt-schaftsinformatik Rundbrief der GI Fachgruppe WI-MobIS, 10(2003)2, S. 89–103. Gesellschaftfur Informatik (GI) e.V., 2003.

[MN05] Mendling, Jan und Markus Nuttgens: EPC Markup Language - An XML-Based Inter-change Format for Event-Driven Process Chains (EPC). Technischer Bericht, Vienna Univer-sity of Economics and Business Administration, Wien, Marz 2005. Verfugbar unter: http:

//wi.wu-wien.ac.at/home/mendling/publications/TR05-EPML.pdf.

[NR02] Nuttgens, Markus und Frank J. Rump: Syntax und Semantik Ereignisgesteuerter Prozess-ketten (EPK). In: Desel, Jorg und Mathias Weske (Hrsg): Promise 2002 - Prozessorien-tierte Methoden und Werkzeuge fur die Entwicklung von Informationssystemen, Proceedings desGI-Workshops und Fachgruppentreffens (Potsdam, Oktober 2002), S. 64–77, Bonn, 2002.

[Obj05] Object Management Group: UML Superstructure Specification, v2.0 (formal/05-07-04), Au-gust 2005. Verfugbar unter: http://www.omg.org/cgi-bin/doc?formal/05-07-04.

[Soi06] Soika, Ralph: BPEL und SOA Architekturen. Imixs Software Solutions GmbH, 2006. Verfugbarunter: http://www.bpm-guide.de/articles/25.

[ST05] Scheer, August-Wilhelm und Oliver Thomas: Geschaftsprozessmodellierung mit der Er-eignisgesteuerten Prozesskette. In: Das Wirtschaftsstudium 34, Nummer 8-9, S. 1069–1078,Saarbrucken, 2005.

[Thea] The Eclipse Foundation: Eclipse - an open development platform. Verfugbar unter: http://www.eclipse.org/.

[Theb] The Eclipse Foundation: Eclipse SDK - API - Class MultiPageEditorPart. Ver-fugbar unter: http://help.eclipse.org/help32/topic/org.eclipse.platform.doc.isv/

reference/api/org/eclipse/ui/part/MultiPageEditorPart.html.

[Thec] The Eclipse Foundation: Graphical Editing Framework (GEF). Verfugbar unter: http:

//www.eclipse.org/gef/.

[W3C06] W3C: Extensible Markup Language (XML) 1.0 (Fourth Edition), September 2006. Verfugbarunter: http://www.w3.org/TR/2006/REC-xml-20060816.

59

http://www.eclipse.org/articles/Article-GEF-diagram-editor/shape.html

http://www.eclipse.org/articles/Article-GEF-diagram-editor/shape.html

http://office.microsoft.com/de-de/visio/default.aspx

http://office.microsoft.com/de-de/visio/default.aspx

http://wi.wu-wien.ac.at/home/mendling/publications/TR05-EPML.pdf

http://wi.wu-wien.ac.at/home/mendling/publications/TR05-EPML.pdf

http://www.omg.org/cgi-bin/doc?formal/05-07-04

http://www.bpm-guide.de/articles/25

http://www.eclipse.org/

http://www.eclipse.org/

http://help.eclipse.org/help32/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/ui/part/MultiPageEditorPart.html

http://help.eclipse.org/help32/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/ui/part/MultiPageEditorPart.html

http://www.eclipse.org/gef/

http://www.eclipse.org/gef/

http://www.w3.org/TR/2006/REC-xml-20060816

Abbildungsverzeichnis


2.1. Metamodell einer EPK in Anlehung an [Lub06] . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2. Funktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3. Ereignis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.4. Prozesswegweiser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.5. eEPK-Elemente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.6. Fallbeispiel ”Bestellung“ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.7. Darstellung eines UML-Aktivitatsdiagramms in Swimlanes in Anlehnung an [BRJ99] . . . . . 15

3.1. Gegenuberstellung - EPK (links) und UML 2.0 Aktivitatsdiagramm (rechts) . . . . . . . . . . 19

4.1. Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2. zugrundeliegende EPK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.3. Variante 1: Anlehnung an UML-Swimlanes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.4. Variante 2: passive Swimlanes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.5. Variante 3: Unabhangige Teilprozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.6. Variante 4: Unabhangige Teilprozesse mit Wartezeitmarkierungen . . . . . . . . . . . . . . . . 274.7. AND-Join-Verknupfung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.8. Moglichkeit 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.9. Moglichkeit 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.10. EPK (links) und Swimlane-Diagramm (rechts) . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.1. Verwendete Variante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.2. Funktion mit einer Organisationseinheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.3. Funktion mit mehreren Organisationseinheiten . . . . . . . . . . . . . . . . . . . . . . . . . . 325.4. Funktion mit mehreren Informationsobjekten . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.5. Ereignis –> Funktion AND-Split . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.6. Funktion –> Ereignis AND-Join (OSD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.7. Funktion –> Ereignis AND-Join (ISD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345.8. Funktion –> Ereignis OR-Join . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345.9. Funktion –> Ereignis OR-Join (ISD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345.10. Funktion –> Ereignis XOR-Join (OSD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.11. Funktion –> Ereignis XOR-Join (ISD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.12. Beispiel einer manuellen Transformation: EPK in klassischer Darstellung . . . . . . . . . . . . 385.13. Beispiel einer manuellen Transformation (Schritt 1) . . . . . . . . . . . . . . . . . . . . . . . . 395.14. Beispiel einer manuellen Transformation (Schritt 2) . . . . . . . . . . . . . . . . . . . . . . . . 405.15. Beispiel einer manuellen Transformation (Schritt 3) . . . . . . . . . . . . . . . . . . . . . . . . 415.16. Beispiel einer manuellen Transformation (Schritt 4) . . . . . . . . . . . . . . . . . . . . . . . . 42

6.1. Das Verhaltnis der Plug-Ins untereinander . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456.2. Plug-In-Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456.3. Metamodell eines Swimlane-Diagramms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

60


7.1. Beispiel fur OSD: EPK in ProFLOW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527.2. Beispiel fur OSD: EPK in LaneEPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537.3. Beispiel fur ISD: EPK in ProFLOW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547.4. Beispiel fur ISD: EPK in LaneEPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Tabellenverzeichnis

2.1. Verknupfungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

5.1. weitere Verknupfungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Listings

2.1. EPML-Elemente als Syntax-Baum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

61

A. Fragebogen

A. Fragebogen

Die folgenden Seiten enthalten den Fragebogen, welcher zur Validierung des Konzeptes dieser Bachelorarbeitverwendet worden ist.

62

A. Fragebogen

Fragebogen 1/4

Fragebogen zur Validierung von Swimlanes in EPK

Diese Befragung soll dazu beitragen das Konzept der Bachelorarbeit „Konzept und Implementierung von Swimlanes in Ereignisgesteuerten Prozessketten“ empirisch zu validieren. Ich bedanke mich daher im Voraus für Ihre Teilnahme.

1 generelle Swimlane-Darstellung

Im Folgenden werden 4 mögliche Varianten zur Darstellung der in Abbildung 1 gezeigten EPK in Swimlanes vorgestellt. In allen Varianten stellt die vertikale Achse die Zeit dar.

Abbildung 1: Beispiel-EPK

Abbildung 2: Variante 1 Abbildung 3: Variante 2

Abbildung 4: Variante 3


Variante 1: Keine Überschneidungen, Swimlanes können einzeln betrachtet werden.

Variante 2: wie Variante 1, mit Verbindungspfeilen zur Darstellung von Weiterführungen(Wartezustand)

Variante 3: Passive Swimlanes. Der Prozess selbst steht nicht in den Swimlanes sondernnur die Verantwortlichkeiten.

Variante 4: Überschneidungen zwischen Swimlanes möglich. Semantisch unklar.

Konzept und Implementierung von Swimlanes in Ereignisgesteuerten Prozessketten

63

A. Fragebogen

Fragebogen 2/4

1.1 Bewerten sie bitte die 4 Varianten: (Schulnoten von 1 bis 6)

Übersichtlichkeit:

Variante 1: _____ Variante 2: _____


Brauchbarkeit (im Betrachten):



Handhabbarkeit (im Erstellen):



1.2 Alles in Allem: Welche Variante würden Sie bevorzugen? ___________

1.3 Für wen könnte das Konzept der Swimlanes interessant sein?

_________________________________________________________________

2 Hierarchie

In Abbildung 6 sehen Sie ein Beispiel für eine hierarchische EPK. Nun ist zu untersuchen, auf welche Art solche Hierarchien in Swimlanes dargestellt werden können.

Abbildung 6: Hierarchie

In Abbildung 7 sehen Sie eine Möglichkeit mit Hierarchien umzugehen. Dabei wird die Hierarchie abgeflacht, so dass es nur noch eine Ebene gibt, die dargestellt wird. Es ist allerdings zu beachten, dass es sich hierbei um ein einfaches Beispiel mit nur einer Unterebene handelt.

Sobald es mehrere Funktionen gibt die u.U. mehrere Unterebenen haben, wird diese Variante sicherlich nicht mehr so übersichtlich sein. Daneben findet sich in Abbildung 8 eine mögliche Darstellung in Swimlanes.

Abbildung 7: Abgeflachte Hierarchie

Abbildung 8: Abgeflacht in Swimlane


64

A. Fragebogen

Fragebogen 3/4

Eine weitere Möglichkeit ist in Abbildung 9 und 10 dargestellt. Hierbei bleiben die Hierarchiengetrennt und werden einzeln in Swimlanes abgebildet.

Abbildung 9: Getrennt (Hauptprozess) Abbildung 10: Getrennt

(Unterprozess)

2.1 Welche dieser beiden Varianten würden Sie bevorzugen?

Abgeflacht Getrennt

2.2 Wie könnte man Hierarchien in Swimlanes noch darstellen?

___________________________________________________________

___________________________________________________________

___________________________________________________________

___________________________________________________________

3 AND-Verknüpfung (Join)

Nun soll Darstellungsmöglichkeiten für eine AND-Join-Verknüpfung aufgezeigt werden. Diese Verknüpfung ist besonders interessant, da innerhalb einer Swimlane geprüft werden muss, ob eine Funktion einer anderen Swimlane ausgeführt wurde.

Variante 1: Es wird in der Swimlane nach Ausführen der Funktion ein Ereignis eingeführt, dasdas Ausführen der eigenen Funktion bestätigt. Dieses wird mit dem gleichwertigen Ereignisder anderen Swimlane AND-verknüpft. Da am Ende eines Prozesses eine Ereignis eintreffenmuss, wird zusätzlich eine Funktion eingeführt. Innerhalb dieser Funktion wird nichtsgemacht. Sie dient lediglich zur Einhaltung der Syntax.

Variante 2: Anstatt Ereignisse einzuführen, wird hier die Funktion der Nachbarswimlaneeingeführt. Allerdings hätte man in diesem Fall Organisationseinheiten innerhalb einerSwimlane, was eigentlich dem Prinzip der Swimlanes widerspricht.

Abbildung 11: AND-Verknüpfung



3.1 Welche Variante würden sie präferieren?

Variante 1 Variante 2

3.2 Wie könnte man eine solche AND-Verknüpfung noch realisieren?

_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________


65

A. Fragebogen

Fragebogen 4/4

4 Dokumente / Informationsobjekte

Im Folgenden soll beispielhaft eine EPK betrachtet werden, in der es darum geht den Inhalt einer Datenbanktabelle in eine neue Datenbanktabelle einer anderen Datenbank zu kopieren.

Besonderes Augenmerk soll hier auf die Notation der Ein- und Ausgaben gelegt werden, welche in der klassischen EPK-Darstellung durch die Pfeile an den Ressourcen gekennzeichnet wird.

In Swimlane DB 1 ist hier eine Variante dargestellt, in der der Datenfluss mittels Pfeilen gekennzeichnet wird.

Eine andere Variante ist in Swimlane DB 2 dargestellt. Hier wird neben den Funktionen der Datenfluss als Textlabel, dargestellt.

Eine dritte Variante wäre es, den Datenfluss direkt in das Label der Funktion einzufügen.

Abbildung 14: EPK Informationsobjekte

Abbildung 15: Swimlane Informationsobjekte

4.1 Welche Variante finden sie am ansprechendsten?

Variante 1 (Pfeile)

Variante 2 (Textlabel)

Variante 3 (Einfügen in Funktion)

5 Anmerkungen (zur freien Verfügung)

____________________________________________________________________________

____________________________________________________________________________

____________________________________________________________________________

____________________________________________________________________________

____________________________________________________________________________

____________________________________________________________________________

____________________________________________________________________________

Vielen Dank für ihre Unterstützung


66

B. Beiliegende CD

B. Beiliegende CD

Auf der am hinteren Einband dieser Arbeit befestigten CD findet sich die folgenden Struktur:

Verzeichnis Inhalt

/thesis Diese Arbeit in elektronischer Form als PDF-Datei/LaneEPC/source Der Quellcode von LaneEPC/LaneEPC/binary LaneEPC im Binar-Format als JAR-Datei/LaneEPC/doc Die JavaDoc-API zu LaneEPC/ProFLOW ProFLOW in einer leicht abgeanderten Version (Erlauterung: siehe unten)

Erlauterungen zur beigefugten ProFLOW-Version

Um Zugriff auf das EPK-Modell von ProFLOW zu gelangen, musste im Plug-In ProFLOW.eepk das PaketproFlow.eepk.model zum Export freigegeben werden. Damit LaneEPC reibungslos verwendet werden kann,wurde diese Anpassung hier vorgenommen. Der Maintainer des Plug-Ins ist benachrichtigt, daher wird dieseAnderung im nachsten Release von ProFLOW wahrscheinlich vorhanden sein.

67

Erklarung

Hiermit versichere ich, dass ich die vorliegende Bachelorarbeit selbststandig und ohne fremde Hilfe verfasstund keine anderen als die in der Arbeit angegebenen Quellen und Hilfsmittel verwendet habe.

Tristan Wehrmaker Bad Salzdetfurth, den 27. Februar 2007

Konzept und Implementierung von Swimlanes in ... · Zusammenfassung Ereignisgesteuerte...

Documents

Transcript of Konzept und Implementierung von Swimlanes in ... · Zusammenfassung Ereignisgesteuerte...