Konzept und Implementierung von Swimlanes in Ereignisgesteuerten Prozessketten

Transkript

1 Gottfried Wilhelm Leibniz Universität Hannover Fakultät für Elektrotechnik und Informatik Institut für Praktische Informatik Fachgebiet Software Engineering Konzept und Implementierung von Swimlanes in Ereignisgesteuerten Prozessketten Bachelorarbeit im Studiengang Informatik von Tristan Wehrmaker Prüfer: Prof. Dr. Kurt Schneider Zweitprüfer: Prof. Dr. Wolfgang Nejdl Betreuer: Dipl.-Wirt.-Inform. Daniel Lübke 27. Februar 2007

2 Zusammenfassung Ereignisgesteuerte Prozessketten können schnell sehr groß und unübersichtlich werden. Je mehr Teilnehmer ein Prozess hat, desto sinnvoller ist es, diesen aus einem großen Prozess einzelne zugeschnittene Teilprozesse anzubieten. Diese Arbeit befasst sich mit der Darstellung von Ereignisgesteuerten Prozessketten in Swimlane-Diagrammen. Diese Swimlane-Darstellung kann eine erhebliche Erleichterung für die betroffenen Benutzergruppen bedeuten.

3 Abstract Event-driven process chains can get very huge and unclear fastly. The more participants a process has the sensiblier it is to offer them their own tailored subprocess from the huge one. This work deals with viewing event-driven process chains in swimlane-diagrams. The swimlane-view can give significant ease to all involved usergroups.

4 Danksagung Ich danke Herrn Daniel Lübke, der mich bei meiner Bachelorarbeit hervorragend betreut und unterstützt hat.

5 Inhaltsverzeichnis Inhaltsverzeichnis 1. Einleitung Motivation Ziel dieser Arbeit Struktur dieser Arbeit Grundlagen Geschäftsprozesse und serviceorientierte Architekturen Ereignisgesteuerte Prozesskette (EPK) Elemente Hierarchie Swimlanes XML EPC Markup Language (EPML) Zusammenfassung Gegenüberstellung von EPK und UML Unified Modeling Language (UML) EPKs und UML-Aktivitätsdiagramme im Vergleich Zusammenfassung Konzeptionelle Untersuchung Einführung in das Konzept Nutzen von Swimlane-Diagrammen Empirische Validierung Fragenblock 1: Swimlane-Darstellungen Fragenblock 2: Hierarchien Fragenblock 3: AND-Join-Verknüpfung Fragenblock 4: Datenflüsse bei Informationsobjekten Zusammenfassung Darstellung von Swimlanes in Ereignisgesteuerten Prozessketten Verwendete Variante Regeln Grundlegende Regeln Einfache Transformationsschritte Verknüpfungen Vorgehen Beispiel-Transformation Zusammenfassung

6 Inhaltsverzeichnis 6. Implementierung Zugrundeliegende Architekturen Eclipse und das Graphical Editing Framework (GEF) ProFLOW LaneEPC Verhältnis zwischen den Plug-Ins Interne Struktur Benutzerinteraktion Transformator Erweiterungsmöglichkeiten Weitere Diagrammtypen und weitere EPK-basierte Prozesstypen Editorenfenster Verschiebung und Skalierung von Elementen EPK-Elemente EPML Zusammenfassung Beispiel Organisations-Swimlane-Diagramm Informations-Swimlane-Diagramm Zusammenfassung und Ausblick Ausblick A. Fragebogen 62 B. Beiliegende CD 67 6

7 Inhaltsverzeichnis Akronyme BPML Business Process Modeling Language BPMN Business Process Modeling Notation eepk EPK erweiterte Ereignisgesteuerte Prozesskette Ereignisgesteuerte Prozesskette EPML Event-Driven-Process-Chain-Markup-Language GEF Graphical Editing Framework HTML Hypertext Markup Language ISD OSD Informations-Swimlane-Diagramm Organisations-Swimlane-Diagramm SGML Standard Generalized Markup Language SOA UML XMI XML Serviceorientierte Architektur Unified Modelling Language XML Metadata Interchange Extensible Markup Language 7

8 1. Einleitung 1. Einleitung 1.1. Motivation In Organisationen treffen immer wieder Mitglieder, die über fachliches Wissen, und Mitglieder, die über methodisches oder technisches Wissen verfügen, aufeinander. Um die fachlichen Arbeitsabläufe zu definieren und an beide Mitgliedergruppen zu kommunizieren, werden Geschäftsprozessmodelle aufgestellt. Durch die Unschärfe der natürlichen Sprache und der vermehrten Unbrauchbarkeit von mathematischen Formulierungen wird daher eine semiformale Beschreibungsform benötigt [ST05]. Als eine dieser Beschreibungsformen erfreut sich heute die Ereignisgesteuerte Prozesskette (EPK), besonders im deutschsprachigen Raum, einer breiten Akzeptanz. EPKs wurden 1992 in Zusammenarbeit mit der SAP AG an der Universität des Saarlandes in Saarbrücken unter der Leitung von Prof. Dr. Dr. h.c. August-Wilhelm Scheer entwickelt. Mit Hilfe von EPKs können Geschäftsprozesse leicht verständlich graphisch dargestellt werden. Mit steigender Komplexität der EPKs kann die Übersichtlichkeit immens sinken. Daher wäre es wünschenswert, eine andere Darstellungsform zu finden, mit der auch große EPKs leichter lesbar werden. Swimlane-Diagramme, wie sie schon aus UML oder BPMN bekannt sind, könnten eine solche Darstellungsform bieten. Sie stellen eine Kombination aus Zuständigkeits- und Flussdiagramm dar. Dadurch ist es für den Betrachter einer solchen Grafik leicht möglich, seine Rolle ausfindig zu machen, seine Verantwortlichkeiten und Entscheidungen zu identifizieren und die zeitliche Abfolge der Prozesse abzulesen Ziel dieser Arbeit In dieser Arbeit soll nun untersucht werden, in welcher Form Swimlanes für die Visualisierung von Ereignisgesteuerten Prozessketten geeignet sein können. Darüber hinaus wird ein Konzept aufgestellt, in dem die Untersuchungsergebnisse beschrieben und umgesetzt werden sollen. Zur Validierung dieses Konzepts soll im Anschluss ein Werkzeug entwickelt werden, das diese Visualisierung leistet. Vom Fachgebiet Software Engineering der Leibniz Universität Hannover wird ein Plug-In für die Entwicklungsumgebung Eclipse namens ProFLOW zur Verfügung gestellt, auf welchem das Werkzeug dieser Arbeit basieren soll Struktur dieser Arbeit Diese Arbeit besteht aus acht Kapiteln. Zuerst werden in Kapitel 2 alle nötigen Grundlagen eingeführt. Dazu werden Geschäftsprozesse in Verbindung mit serviceorientierten Architekturen beschrieben, Ereignisgesteuerte Prozessketten und Swimlanes erläutert, sowie die Beschreibungssprache EPML vorgestellt. Nach dieser Einführung folgt in Kapitel 3 eine Gegenüberstellung der Unified Modeling Language (UML) und der Ereignisgesteuerten Prozesskette (EPK). Hier wird UML und das dazugehörige Aktivitätsdiagramm 8

9 1. Einleitung vorgestellt und dann mit der EPK verglichen. Im Anschluss daran behandelt Kapitel 4 eine Einführung in das Konzept, gefolgt von modelltheoretischen Untersuchungen und einer empirischen Befragung zur Validierung von ersten Konzeptansätzen. In Kapitel 5 werden dann mögliche Darstellungen von Swimlanes beschrieben, sowie Regeln und Vorgehensweisen zur Erstellung von Swimlane-Diagrammen vorgestellt. Kapitel 6 behandelt die Implementierung dieses Konzepts in ein Plug-In für die Entwicklungsumgebung Eclipse. Dabei wird auf die zugrundeliegenden Architekturen eingegangen und der Aufbau des zu entwickelnden Plug-Ins LaneEPC erläutert. Nachdem die Implementierung abgehandelt wurde, wird im siebten Kapitel jeweils ein Beispiel für ein Swimlane-Diagramm, das mittels Organisationseinheiten aufgebaut ist, und ein Swimlane-Diagramm, das mittels Informationsobjekten aufgebaut ist, in LaneEPC dargestellt. Im Anschluss daran werden die durch diese Arbeit gewonnen Erkenntnisse zusammengefasst und ein Ausblick auf mögliche Erweiterungen des Konzeptes gegeben. 9

10 2. Grundlagen 2. Grundlagen Dieses Kapitel wird einen Überblick über die Bereiche geben, die für diese Arbeit grundlegend sind. Dazu werden zuerst Geschäftsprozesse im Zusammenhang mit serviceorientierten Architekturen behandelt. Dabei wird die Notwendigkeit für die danach erläuterte Ereignisgesteuerte Prozesskette herausgestellt. Im darauf folgenden Abschnitt werden dann Swimlanes anhand eines Beispiels aus der Unified Modeling Language vorgestellt Geschäftsprozesse und serviceorientierte Architekturen Werden in einem Unternehmen Leistungen erstellt, laufen eine Vielzahl von Arbeitsschritten ab. Der Ablauf dieser Arbeitsschritte wird als Geschäftsprozess bezeichnet. Dabei finden sich heute in jedem Unternehmen Geschäftsprozesse, auch wenn diese insbesondere in kleinen Unternehmen nicht formal beschrieben werden. Besonders zur Optimierung der Geschäftsprozesse ist es aber von Nutzen, diese formal zu spezifizieren [Int06]. Eine Definition der Geschäftsprozesse gibt Ulrich Frank in [FvL03]: Definition 1 (Geschäftsprozess): Ein Geschäftsprozess ist eine wiederkehrende Abfolge von Aktivitäten, die mehr oder weniger rigiden Regelungsmustern genügt. Er ist zielgerichtet und steht in einem direkten Zusammenhang mit der marktgerichteten Leistungserstellung eines Unternehmens. [... ] Die Ausführung von Geschäftsprozessen erfordert den Einsatz knapper Ressourcen. Da Geschäftsprozesse also festlegen, welche Vorgänge innerhalb eines Unternehmens durch welche Rollen ausgeführt werden sollen [LGS05], wird sich diese Arbeit besonders mit diesen Rollen beschäftigen. In vielen Fällen ist es nun sinnvoll, diese Geschäftsprozesse durch Softwaresysteme unterstützen oder automatisieren zu lassen. Da jedoch die Konfiguration und Anpassung von Standardsoftwarelösungen sehr aufwändig und kostenintensiv ist, wird vermehrt auf sogenannte serviceorientierte Architekturen (SOA), wie zum Beispiel Web Services, gesetzt. Ziel der SOA ist es, eine Lösung der Kopplung zwischen interagierenden Softwareagenten zu erreichen. Als Beispiel für eine solche serviceorientierte Architektur könnte man einen Bonitäts-Service nennen [Soi06]. Ein solcher Service, der die Bonität von Kunden prüfen und in einer Vielzahl von Anwendungen benutzt werden soll, muss nur einmal bereitgestellt werden. Wird nun zum Beispiel ein neues Prüfungsverfahren eingeführt, so wird der Service nur zentral angepasst und diese Änderung automatisch allen Anwendungen zur Verfügung gestellt. Die Anwendungen selbst müssen nicht angepasst werden. In SOA müssen Business-Funktionen nicht neu programmiert, sondern nur orchestriert, also nur noch existierende Services neu zusammengestellt, werden. So ist es leicht möglich, Programmteile auszutauschen, bzw. den gesamten Prozess umzustellen. Eine Möglichkeit, die Anforderungen für solche Orchestrierungen aufzustellen, sind die Ereignisgesteuerten Prozessketten, welche im folgenden Abschnitt erläutert werden. 10

11 2. Grundlagen 2.2. Ereignisgesteuerte Prozesskette (EPK) Die Ereignisgesteuerte Prozesskette wurde 1992 am Institut für Wirtschaftsinformatik der Universität des Saarlandes in Saarbrücken, in Zusammenarbeit mit der SAP AG, entwickelt. Ihr Ziel ist die Dokumentation von Geschäftsprozessen [KNS92]. Sie besteht im Wesentlichen aus den Elementen Funktion, Ereignis, Prozesswegweiser und drei Arten von Verknüpfungen, welche im folgenden Abschnitt vorgestellt werden. Von einer formalisierten Erläuterung der Syntax und Semantik wird hier aus Platzgründen Abstand genommen. Ausführliche Informationen hierzu finden sich in [NR02]. Abbildung 2.1.: Metamodell einer EPK in Anlehung an [Lüb06] Elemente Funktion Der Begriff der Funktion kann auf verschiedene Arten definiert werden. So wird der Begriff in der Mathematik als eine Vorschrift angesehen, in der jedem Element einer Menge genau ein Element einer zweiten Menge zugeordnet wird. Hier wird der Begriff Funktion vielmehr als eine Aufgabe, d.h. als physische oder geistige Aktivität zur Erfüllung eines definierten Soll-Zustands, verstanden. Abbildung 2.2.: Funktion 11

12 2. Grundlagen Funktionen stellen dabei die einzigen aktiven Elemente in einer Ereignisgesteuerten Prozesskette dar. Ausserdem können Funktionen weitere Prozesse beinhalten. Diese Tatsache wird in Abschnitt beschrieben. Als Symbol für eine Funktion wird in der EPK ein abgerundetes Rechteck verwendet. Ereignis In Anlehnung an die DIN ist ein Ereignis das Eingetretensein eines definierten Zustands, der eine Folge von Aktivitäten bewirkt [KNS92]. Ereignisse werden dabei durch folgende Eigenschaften gekennzeichnet: Ereignisse repräsentieren einen eingetretenen Zustand. Ereignisse dienen zur Spezifikation betriebswirtschaflicher Bedingungen. Ereignisse können Funktionen auslösen. Ereignisse können Prozesswegweiser auslösen. Funktionen werden durch Ereignisse ausgelöst. Prozesswegweiser werden durch Ereignisse ausgelöst. Abbildung 2.3.: Ereignis Abbildung 2.3 zeigt exemplarisch die Darstellung eines Ereignis-Elements als Hexagon. Prozesswegweiser EPK-Modelle können durch Prozesswegweiser in Beziehung zueinander gesetzt werden. Dabei werden sie als Verbindung zu Vorgänger- bzw. Nachfolgerprozessen verwendet. Prozesswegweiser haben entweder genau eine eingehende oder genau eine ausgehende Kante, daher können sie nur am Anfang oder am Ende einer Ereignisgesteuerten Prozesskette stehen. Abbildung 2.4.: Prozesswegweiser Als Symbol für einen Prozesswegweiser wird in der EPK ein Ereignissymbol und ein Funktionssymbol überlappend dargestellt (siehe Abbildung 2.4). Verknüpfungen In Ereignisgesteuerten Prozessketten existieren drei Verknüpfungsarten, um Ereignisse, Funktionen und Prozesswegweiser zu verknüpfen. Als Verknüpfung werden die AND-, OR- und XOR-Operatoren der booleschen Algebra verwendet. Dabei müssen auf den Seiten der Verknüpfung jeweils unterschiedliche Elemente stehen. 12

13 2. Grundlagen So muss zum Beispiel, wenn Funktionen miteinander verknüpft werden, ein Ereignis folgen. Die drei Verknüpfungsarten werden in Tabelle 2.1 zusammengefasst. Desweiteren wird zwischen Split- und Join-Verknüpfungen unterschieden. Dabei wird mittels Split-Verknüpfungen der Prozess in mehrere Pfade geteilt und mittels Join-Verknüpfungen wieder zusammengeführt. Da Ereignisse keine Entscheidungen treffen können, dürfen auf diese ausserdem keine OR- oder XOR-Split- Verknüpfungen 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.: Verknüpfungen Erweiterte Ereignisgesteuerte Prozesskette Im Folgenden werden drei Arten von Objekten beschrieben, welche im Zuge der erweiterten Ereignisgesteuerten Prozesskette (eepk) zur Definition von EPKs hinzugefügt worden sind. Diese Objekte stehen im Mittelpunkt der in dieser Arbeit aufgestellten Untersuchungen. Abbildung 2.5.: eepk-elemente Die in Abbildung 2.5 dargestellten Objekte können nur mit Funktionen, aber nicht mit Ereignissen verbunden sein. So ist es für den Geschäftsprozess nur relevant, welche Informationen für die Ausführung einer Funktion benötigt werden, wer diese Funktion ausführt und ob eine Anwendung dafür benötigt wird. Es ist aber nicht von Relevanz, wer z.b. ein Ereignis ausgelöst hat. Organisationseinheiten stehen für Personen oder Abteilungen, die an einer Funktion beteiligt sind. Informationsobjekte stellen ein Datenobjekt dar. Dies können zum Beispiel Dokumente oder Datenbanken sein. Desweiteren können Anwendungen, also unterstützende Softwaresysteme, an Funktionen beteiligt sein. Dabei werden Organisationseinheiten und Anwendungen durch einfache Linien mit den Funktionen verbunden. Bei Informationsobjekten werden zur Kennzeichnung der Richtung des Datenflusses Pfeile verwendet. 13

14 2. Grundlagen Hierarchie Man unterscheidet zwischen flachen und hierarchischen Ereignisgesteuerten Prozessketten. Dabei bestehen flache EPKs nur aus einer Ebene und stellen damit den trivialen Fall einer EPK dar. In den meisten Fällen verhält 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 in der nächsten Hierarchieebene weiter unterteilt und so detailliert. So könnte man sich zum Beispiel vorstellen, dass die Funktion Artikel versenden auch noch weiter präzisiert wird. Abbildung 2.6.: Fallbeispiel Bestellung 2.3. Swimlanes Swimlanes - in der Literatur auch Schwimmbahn [Jec], Verantwortlichkeitsbereich [BRJ99] oder Partition [Obj05] genannt - sind eine Darstellungsmöglichkeit für Verantwortlichkeiten, wie sie zum Beispiel aus UML oder der BPMN bekannt ist. Sie zeigen dem Betrachter sehr direkt auf, wofür er die Verantwortung trägt. Dabei werden den verschiedenen Beteiligten - zum Beispiel Abteilungen - in der graphischen Darstellung des Geschäftsprozesses einzelne Bereiche zugeordnet. In Anlehnung an [Boo01] kann folgende Definition gegeben werden: 14

15 2. Grundlagen Definition 2 (Swimlane): Ein Swimlane-Diagramm ist eine Abbildung zum Darstellen von Folgen von Aufgaben und Entscheidungen in einem Prozess. [...] Die horizontale Dimension des Swimlane-Diagramms bezeichnet die Zeit. Die vertikale Dimension besteht aus Bändern oder Schwimmbahnen, wobei jede Schwimmbahn für eine Organisation oder eine spezielle Rolle steht. Die Aufgaben werden von den Organisationen (Schwimmbahnen) ausgeführt, in denen sie sich befinden. Dabei sei angemerkt, dass die in dieser Definition angegebene Ausrichtung der horizontalen und vertikalen Dimensionen in dieser Ausarbeitung vertauscht wird. Es ist in Ereignisgesteuerten Prozessketten allgemein üblich, dass die vertikale Achse die Zeit darstellt. Abbildung 2.7.: Darstellung eines UML-Aktivitätsdiagramms in Swimlanes in Anlehnung an [BRJ99] Abbildung 2.7 verdeutlicht den Vorteil einer Einteilung in Swimlanes am Beispiel eines UML-Aktivitätsdiagramms. Auf der linken Seite sieht man die übliche Notation eines Aktivitätsdiagramms, auf der rechten 15

16 2. Grundlagen Seite ist der Graph um Swimlanes für die Organisationseinheiten Kunde, Vertrieb und Lager erweitert. Somit können die Angehörigen dieser Organisationseinheiten auf einen Blick ihre Aufgaben und den zeitlichen Ablauf ablesen. Dabei sind Swimlanes in UML-Aktivitätsdiagrammen die einzige Möglichkeit, Verantwortlichkeiten darzustellen XML Die Extensible Markup Language (XML) wurde 1996 vom W3 Consortium entwickelt. Sie ist dabei abgeleitet von SGML, auf welcher zum Beispiel auch die Hypertext Markup Language (HTML) basiert. XML wurde mit den folgenden Zielen definiert [W3C06]: XML soll direkt über das Internet verwendbar sein. XML soll eine Vielzahl von Anwendungen unterstützen. Programme, die XML-Dokumente verarbeiten, sollen einfach zu schreiben sein. XML-Dokumente sollen für den Menschen lesbar und halbwegs anschaulich sein. Das Design von XML soll formal und präzise sein. XML-Dokumente sollen leicht erstellt werden können. Auf Basis von XML sind mit der Zeit viele Formate für spezielle Anwendungsfälle entstanden. Bei diesen unterscheidet man zwischen schwacher und starker Standardunterstützung [MN03]. Eine schwache Standardunterstützung ist gekennzeichnet durch ein produktabhängiges und damit proprietäres XML Schema. Dadurch kommt es zu einer Vielzahl von heterogenen Werkzeugen, die alle unterschiedliche XML-Formate unterstützen, unter welchen mittels Transformationsprogrammen vermittelt werden muss. Starke Standardunterstützung hingegen setzt auf anerkannte XML-Austauschformate, so können Werkzeuge durch andere ersetzt werden, ohne dass sich an den Daten etwas ändert. Für diverse Modellierungskonzepte haben sich derartige Standards heute etabliert, so zum Beispiel XML Metadata Interchange (XMI) für UML, die Business Process Modeling Language (BPML) für die Business Process Modeling Notation (BPMN) und auch die Event-Driven-Process-Chain-Markup-Language (EPML) für Ereignisgesteuerte Prozessketten, welche im nächsten Abschnitt beschrieben wird EPC Markup Language (EPML) Listing 2.1 gibt einen Überblick über die Elemente von EPML. Dabei soll hier nur kurz auf die wichtigsten Elemente eingegangen werden. Eine ausführliche Beschreibung findet sich in [MN05]. Das epml-element stellt das Rootelement dar. Über das graphicsdefault-element können verschiedene graphische Richtlinien festgelegt werden, welche dann von Visualisierungswerkzeugen verwendet werden können. Die Einstellungen gelten für alle EPK-Elemente, sofern für diese im graphics-element keine Informationen hinterlegt 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 finden sich die Ereignisse, Funktionen, Verknüpfungen usw. 16

17 2. Grundlagen Wird ein EPK-Element in mehreren EPK-Modellen verwendet - wie z.b. bei hierarchischen EPKs -, können Referenzen erstellt werden. Dies geschieht durch das definitions-element. epml documentation? 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) name description attributetypes? attributetype* (typeid) description directory (name) directory* (name)... epc* (epcid, name) attribute* (typeref, value) event* (id, defref)... function* (id, defref) name description? 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 für diese Arbeit wichtigen Grundlagen eingeführt. Dazu wurde der Begriff Geschäftsprozess und dessen Verbindung zu serviceorientierten Architekturen vorgestellt. Hier wurde gezeigt, welche Vorteile diese Architekturen bieten können. Im Anschluss daran wurde die Ereignisgesteuerte Prozesskette, sowie deren Elemente und die Bedeutung der Hierarchien beschrieben. Danach wurde die Swimlane-Darstellung anhand eines UML-Aktivitätsdiagramms vorgestellt. Zum Abschluss dieses Kapitels wurde dann die Extensible Markup Language (XML) in Zusammenhang mit schwacher und starker Standardunterstützung erläutert und mit dem im darauffolgenden Abschnitt erläuterten XML-Dialekt für Ereignisgesteuerte Prozessketten (EPML) in Verbindung gebracht. 17

18 3. Gegenüberstellung von EPK und UML 3. Gegenüberstellung von EPK und UML In diesem Kapitel sollen nun die Konzepte der Unified Modelling Language (UML) und der Ereignisgesteuerten Prozesskette gegenübergestellt werden. Dazu soll gezeigt werden, in welchen Fällen welches Konzept genutzt wird Unified Modeling Language (UML) Die Unified Modeling Language wurde von der Object Management Group (OMG) entwickelt und standardisiert. Dabei stellt die UML heute eine der dominierenden Sprachen zur Modellierung von Softwaresystemen dar. So bietet sich durch ihre objektorientierte Modellierung eine Verbindung zu objektorientierten Programmiersprachen wie Java und C++. Diese Verbindung wird oftmals durch Codegeneratoren genutzt, um die UML-Modelle in Code der jeweiligen Programmiersprache zu konvertieren. In der aktuellen Version 2.0 besteht die UML aus dreizehn Diagrammtypen, dabei unterscheidet man zwischen 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: Aktivitätsdiagramm (activity diagram) Interaktionsdiagramme (interaction diagrams): Sequenzdiagramm (sequence diagram) Kommunikationsdiagramm (communication diagram) Interaktionsüberblickdiagramm (interaction overview diagram) Zeitverlaufsdiagramm (timing diagram) Anwendungsfalldiagramm (use case diagram) Zustandsdiagramm (state machine diagram) Aus dieser Vielzahl von Diagrammarten kommen die Aktivitätsdiagramme den Ereignisgesteuerten Prozessketten am nächsten. Eine Gegenüberstellung dieser beiden Diagramme befindet sich im folgenden Abschnitt. 18

19 3. Gegenüberstellung von EPK und UML 3.2. EPKs und UML-Aktivitätsdiagramme im Vergleich Zu Beginn dieser Gegenüberstellung soll nun zuerst auf die Unterschiede und Ähnlichkeiten in den Notationen von UML-Aktivitätsdiagrammen und Ereignisgesteuerten Prozessketten eingegangen werden. Danach werden die Einsatzgebiete dieser Modellierungen beschrieben. Abbildung 3.1.: Gegenüberstellung - EPK (links) und UML 2.0 Aktivitätsdiagramm (rechts) In Abbildung 3.1 wird ein Geschäftsprozess auf zwei verschiedene Weisen dargestellt. Links sieht man die Darstellung als Ereignisgesteuerte Prozesskette und rechts als UML-Aktivitätsdiagramm. Die Abbildung beschreibt einen Geschäftsprozess, in dem die Bearbeitung einer Bestellung formuliert ist. Dabei zeigen sich schon auf den ersten Blick mehrere Unterschiede in der Notation: 19

20 3. Gegenüberstellung von EPK und UML Die Organisationseinheiten werden in EPKs als Elemente an die Funktionen geschrieben. In UML hingegen ist nur eine Notation in Swimlanes möglich. Die in EPKs verwendeten Ereignisse treten in UML nicht auf. Sie werden hier indirekt durch Zustandstransitionen modelliert. XOR-Verknüpfungen werden in UML durch sogenannte Entscheidungskristalle realisiert. Eine Bedingung für die Entscheidung wird ggf. an der folgenden Transition vermerkt. AND-Verknüpfungen werden in UML als Parallelisierungs- bzw. Synchronisationsbalken dargestellt. Für OR-Verknüpfungen gibt es in der UML keine eigene Notation. Diese können lediglich durch Bedingungen an Synchronisationsbalken dargestellt werden. Informationsobjekte werden in UML nicht, wie in EPKs an die betreffende Funktion notiert, sondern stehen als eigenständige Objekte im Kontrollfluss. Desweiteren sind in UML-Aktivitätsdiagrammen keine Zuordnungen von Daten zu Aktionen möglich, wodurch Geschäftsregeln nur eingeschränkt darstellbar sind [Dan99]. Ursprünglich liegt der Verwendungszweck der Unified Modeling Language in der Modellierung von Softwaresystemen. Die Modellierung von Geschäftsprozessen war zum Einen nicht vorgesehen und zum Anderen nur schwer möglich. Um dieses Manko zu beseitigen und den Markt der Geschäftsprozesse zu erschließen, wurden in der Spezifikation zu UML in der Version 2.0 einige Erweiterungen zur Notation von Aktivitätsdiagrammen hinzugefügt. Der ursprüngliche Verwendungszweck der Ereignisgesteuerten Prozesskette und damit auch ihre Stärke liegt in der Modellierung von Geschäftsprozessen. Somit ist keine implementierungsnahe Modellierung vorgesehen, wie sie von UML forciert wird. Die Unified Modeling Language wird traditionell hauptsächlich im Umfeld des Software-Engineerings verwendet. Demgegenüber hat sich die Ereignisgesteuerte Prozesskette besonders ausserhalb des Software- Engineerings einen Namen gemacht. Dies liegt wohl vor allem daran, dass in der UML Abläufe sehr granular beschrieben werden, wie es für Softwaresysteme gebraucht wird. Die Ereignisgesteuerte Prozesskette hingegen dient viel mehr der Beschreibung von Anforderungen für Softwaresysteme. Dadurch ist vor allem interessant, was ein System bzw. ein Benutzer des Systems in einer bestimmten Situation macht - nicht jedoch wie es bzw. er dies macht Zusammenfassung In diesem Kapitel wurde ein kurzer Einblick in die Unified Modeling Language (UML) gegeben. Im Anschluss daran wurden die Notationen von Ereignisgesteuerten Prozessketten und UML-Aktivitätsdiagrammen verglichen und die Unterschiede dargelegt. In der darauf folgenden Beschreibung des Verwendungszweckes hat sich herausgestellt, dass UML-Aktivitätsdiagramme ihre Verwendung in der Modellierung von Softwaresystemen findet. Hingegen werden Ereignisgesteuerte Prozessketten für die Modellierung von Geschäftsprozessen und zur Notation von Anforderungen für Softwaresysteme verwendet. 20

21 4. Konzeptionelle Untersuchung 4. Konzeptionelle Untersuchung In diesem und dem darauffolgenden Kapitel soll nun ein Konzept entworfen werden, das es ermöglicht, Ereignisgesteuerte Prozessketten mit Hilfe von Swimlanes darzustellen. Dazu wird zuerst eine kurze Einführung in das Konzept gegeben, woraufhin dann im Folgenden der Nutzen von Swimlanes in EPKs beschrieben wird. Im Anschluss daran wird auf eine empirische Befragung, welche zu dieser Arbeit durchgeführt wurde, eingegangen Einführung in das Konzept Das Ziel dieses Konzeptes soll es sein, die Ereignisgesteuerte Prozesskette, als eine abstrakte Beschreibung eines Geschäftsprozesses, von der klassischen EPK-Darstellung in eine Swimlane-Darstellung zu transferieren. Abbildung 4.1 zeigt diesen Sachverhalt. Dabei stellt der untere Kasten die Ereignisgesteuerte Prozesskette dar. Auf der linken Seite findet man die klassische Darstellung für EPKs und auf der rechten Seite symbolisch die hier zu entwickelnde Swimlane-Darstellung. In den folgenden Abschnitten werden dazu mehrere Ansätze vorgestellt. Abbildung 4.1.: Konzept 21

22 4. Konzeptionelle Untersuchung Auf dem Softwaremarkt vertreibt die Firma Gedilan die Software Nautilus, die Ereignisgesteuerte Prozessketten als Swimlane-Diagramme darstellen kann [Ged]. Allerdings ist es hier nicht einfach möglich, zwischen den verschiedenen Darstellungen zu wechseln. Dabei handelt es sich hierbei vielmehr um ein komplettes Managment-System, daher kann man EPKs nicht selber zeichnen, sondern nur fertig eingegebene Geschäftsprozesse anzeigen bzw. sich daraus Präsentationen erstellen lassen. Der Ansatz zur Darstellung von Swimlanes, 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 Ereignisgesteuerten Prozessketten möglich ist [Mic]. Dabei existieren keinerlei Automatismen zur Syntaxüberprüfung oder zur Darstellung als Swimlane-Diagramm. Letzteres ist nur unter Verwendung der UML-Shapes für Swimlanes möglich. Daher unterscheidet es sich nicht von normalen Zeichenprogrammen, wie dem vor allem unter Linux bekannten Dia Diagrammeditor [Lar] Nutzen von Swimlane-Diagrammen In diesem Abschnitt soll beantwortet werden, für wen die Modellierung von Swimlanes in Ereignisgesteuerten Prozessketten von Nutzen ist und welche Qualitätsmerkmale von Bedeutung sind. In erster Linie kann man sich vorstellen, dass Swimlanes für die Betrachter von Geschäftsprozessdiagrammen eine erhebliche Erleichterung darstellen können. So müssen diese ihre Konzentration nur auf ihren Bereich richten. Damit ist für sie nur relevant, was ausserhalb ihrer Bereiche passiert, wenn sie mit anderen gemeinsam an einer Aufgabe arbeiten. Auf Seiten des Modellierers ist es natürlich sehr wünschenswert, den Beteiligten auf sie zugeschnittene Prozesse bieten zu können. Dadurch stellt sich eine erhebliche Kosten- und Zeitersparnis heraus. Es kommt zwar ein geringer Zeitaufwand auf den Modellierer zu, allerdings können sich so die Beteiligten schneller auf den Prozess einstellen. Die Mehrkosten eines Modellierers bzw. einer Modellierergruppe stehen so den Minderkosten aller anderen Beteiligten gegenüber. Von höchster Bedeutung für den Nutzen von Swimlanes in Ereignisgesteuerten Prozessketten ist, so wenig Veränderungen wie möglich an der Notation von EPKs vorzunehmen, um die Einstiegshürden möglichst gering zuhalten. So sollte die Darstellung besonders für Nutzer, die keine Erfahrungen in der Modellierung von Geschäftsprozessen haben, keine große Umstellung sein Empirische Validierung Zur Validierung des hier vorgestellten Konzeptes wurde im Rahmen des Projektes Entwicklung einer Webservice-basierten Anwendung im Fachgebiet Software Engineering der Leibniz Universität Hannover eine empirische Befragung durchgeführt. In dieser Befragung haben zehn Projektteilnehmer Grundsatzfragen bezüglich des Konzeptes beantwortet. Der verteilte Fragebogen bestand aus vier Frageblöcken, welche im Folgenden erläutert werden. Die in diesem Abschnitt gezeigten Abbildungen sind im Gegensatz zu den Abbildungen im Fragebogen aus Platzgründen teilweise gekürzt. Der vollständige Fragebogen findet sich im Anhang dieser Arbeit. 22

23 4. Konzeptionelle Untersuchung Fragenblock 1: Swimlane-Darstellungen Der erste Fragenblock behandelt eine Gegenüberstellung der möglichen Swimlane-Darstellungen. Abbildung 4.2 zeigt die für diesen Fragenblock zugrundegelegte Ereignisgesteuerte Prozesskette, in der das Eingehen eines Kundenauftrages bearbeitet wird. Dazu sollten die Befragten ihre Meinung zu den Bereichen Übersichtlichkeit, Brauchbarkeit (beim Betrachten) und mögliche Handhabbarkeit (beim Erstellen) in Schulnoten ausdrücken. Abbildung 4.2.: zugrundeliegende EPK Anschließend war eine bevorzugte Variante zu wählen. Besonders interessant ist bei diesem Block, dass oftmals eine Variante als Bevorzugte ausgewählt wurde, welche bei der Bewertung nach Schulnoten schlechter ausgefallen ist. Weiter wurde in diesem Block danach gefragt, für wen das Konzept der Swimlanes interessant sein könnte. Die in diesem Fragenblock behandelten Varianten sollen nun beschrieben werden: Variante 1: Anlehnung an UML-Swimlanes Eine Möglichkeit, Swimlane-Diagramme darzustellen, ist, wie bei Aktivitätsdiagrammen der Unified Modeling Language vorzugehen. Dabei werden die Elemente der zugrundegelegten EPK einfach in die jeweiligen Swimlanes verschoben. Daher überschneiden die Transitionen die Grenzen der Swimlanes und sorgen so in vielen Fällen für unübersichtliche Diagramme. 23

24 4. Konzeptionelle Untersuchung Wie man in Abbildung 4.3 sieht, können hier, insbesondere im Falle von Verknüpfungen, semantische Unklarheiten auftreten. So lassen sich Verknüpfungen oftmals nicht eindeutig einem einzelnen Bereich zuordnen. Ein weiterer Nachteil dieser Darstellung ist, dass die Swimlane-Bereiche nicht unabhängig voneinander betrachtet werden können. Abbildung 4.3.: Variante 1: Anlehnung an UML-Swimlanes Bei den Befragten konnte diese Variante lediglich in der Handhabbarkeit für den Modellierer punkten. Dies lässt sich auch leicht begründen, da der Modellierer beim Erstellen eines solchen Diagramms nur wenige Regeln einhalten muss. Bei der Frage nach der bevorzugten Variante haben sich erstaunlicherweise 50% der Befragten für diese Variante entschieden, wobei sie in der Bewertung nach Schulnoten eher mittelmässig abgeschnitten hat. 24

25 4. Konzeptionelle Untersuchung Variante 2: passive Swimlanes Eine weitere Möglichkeit 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 die Organisationseinheiten bzw. Informationsobjekte. Abbildung 4.4.: Variante 2: passive Swimlanes Diese Darstellung stellt die geringste Veränderung der klassischen EPK-Darstellung dar. Durch die Verlagerung der Organisationseinheiten bzw. Informationsobjekte ausserhalb der EPK, wird eine Vielzahl der Diagramme wahrscheinlich weitaus unübersichtlicher. Dies ist wohl auch der Grund, warum diese Variante in der empirischen Validierung mit Abstand am schlechtesten abgeschnitten hat. Sie wurde von keinem Befragten als Bevorzugte gewählt. 25

26 4. Konzeptionelle Untersuchung Variante 3: Unabhängige Teilprozesse In Verbindung mit My own process: Providing dedicated views on EPCs [GRvdA05] und Multiperspektivische ereignisgesteuerte Prozesskette [BDFK03] kann diese Variante abgeleitet werden. Dabei wird jede beteiligte Organisationseinheit bzw. jedes Informationsobjekt einzeln betrachtet und für diese ein eigener Teilprozess zugeschnitten. Abbildung 4.5 zeigt exemplarisch eine solche Darstellung. Der Vorteil dieser Variante ist, dass in den Swimlanes vollwertige Prozesse stehen, die unabhängig von den Nachbarswimlanes betrachtet werden können. Abbildung 4.5.: Variante 3: Unabhängige Teilprozesse Diese Variante hat insbesondere bei der Frage nach der Übersichtlichkeit sehr gut abgeschnitten. Allerdings wurde sie nur von einem Befragten als Bevorzugte gewählt. 26

27 4. Konzeptionelle Untersuchung Variante 4: Unabhängige Teilprozesse mit Wartezeitmarkierungen In Variante 4 wird Variante 3 um Verbindungskanten erweitert. Dabei werden, im Falle von Unterbrechungen des Prozesses in einer Swimlane, Kanten eingeführt. Diese Kanten symbolisieren die Wartezeit, bis der Teilnehmer wieder weitermachen kann. Abbildung 4.6.: Variante 4: Unabhängige Teilprozesse mit Wartezeitmarkierungen Diese Variante unterscheidet sich nicht sehr von Variante 3. Um so erstaunlicher ist das Ergebnis der Befragung. Dabei hat diese Variante in der Übersichtlichkeit und Brauchbarkeit beim Betrachten bessere Noten als Variante 3 erhalten, hat aber bei der Handhabbarkeit beim Modellieren wesentlich schlechter abgeschnitten. Dennoch entschieden sich 30% für diese Variante. Daraus lässt sich schließen, dass die zeitliche Komponente eine besondere Rolle spielt. Diese Erkenntnis wird für die Entwicklung der in diesem Konzept verwendeten Variante von großer Wichtigkeit sein (siehe Abschnitt 5.1) Fragenblock 2: Hierarchien In einem zweiten Fragenblock wurden zwei Möglichkeiten zur Verarbeitung von Hierarchien in Swimlane- Diagrammen vorgestellt. Dabei wurde gefragt, ob Hierarchien entweder abgeflacht oder getrennt behandelt werden sollten. 70% der Befragten waren der Meinung, dass Hierarchien abgeflacht werden sollte, also dass die Hierarchie auf eine Ebene heruntergebrochen wird. Der Vorteil dieser Abflachung ist, dass Hierarchien nicht gesondert betrachtet werden müssen. Bei tiefen Hierarchien könnte dies aber auch zu sehr großen, teils unübersichtlichen Darstellungen führen. 27

28 4. Konzeptionelle Untersuchung Fragenblock 3: AND-Join-Verknüpfung Ein dritter Fragenblock behandelte eine AND-Join-Verknüpfung, wie sie in Abbildung 4.7 dargestellt ist. Abbildung 4.7.: AND-Join-Verknüpfung Bei dieser Verknüpfung muss z.b. innerhalb von Swimlane A überprüft werden, ob eine Funktion in Swimlane B ausgeführt wurde. Dazu wurden in dieser Befragung zwei Möglichkeiten vorgestellt. Möglichkeit 1 ist in Abbildung 4.8 dargestellt. Bei dieser Möglichkeit wird die Funktion der anderen Swimlane mit übernommen und mit dem Symbol für die Organisationseinheit gekennzeichnet. Dadurch fällt eine Inkonsistenz in der Darstellung auf, da so Symbole für Organisationseinheiten bzw. Informationsobjekte im Swimlane-Diagramm vorkommen, was dem Sinn der Swimlanes widerspricht. Abbildung 4.8.: Möglichkeit 1 Für Möglichkeit 2, wie sie in Abbildung 4.9 dargestellt ist, haben sich 70% der Befragten entschieden. Eine genaue Beschreibung dieser Darstellung findet sich in Abschnitt Abbildung 4.9.: Möglichkeit 2 28

29 4. Konzeptionelle Untersuchung Fragenblock 4: Datenflüsse bei Informationsobjekten Der letzte Fragenblock behandelte die Darstellung von Swimlane-Diagrammen, welche anhand von Informationsobjekten aufgebaut werden. Dabei ging es um die Frage, wie die Datenflüsse von einem Informationsobjekt zu einer Funktion bzw. andersherum dargestellt werden könnten. Abbildung 4.10 zeigt links eine Ereignisgesteuerte Prozesskette mit Informationsobjekten in der klassischen Darstellung und rechts eine zugehörige Swimlane-Darstellung. Die gegebene EPK steht als Beispiel für einen Prozess, in dem Datenbanktabellen von einer in eine andere Datenbank kopiert werden sollen. Abbildung 4.10.: EPK (links) und Swimlane-Diagramm (rechts) Eine Möglichkeit zur Notation des Datenflusses ist, ihn als Text in die Beschriftung der Funktion einzufügen. In einer weiteren Möglichkeit wurde ein Textlabel neben der Funktion platziert (siehe Swimlane DB 2). Für die dritte gegebene Möglichkeit entschieden sich 80% der Befragten. Dabei handelt es sich um eine Variante, in der Pfeile mit der Flussrichtung als Aufschrift zur Funktion, bzw. von der Funktion weg zeigen (siehe Swimlane DB 1). Diese Variante wird schlussendlich auch in der in Abschnitt 5.3 vorgestellten Transformation von EPK-Diagrammen anhand von Informationsobjekten verwendet Zusammenfassung Das vorangegangenen Kapitel führte in das zu erarbeitende Konzept. Dazu stellte es den Nutzen für Betrachter und Modellierer von Ereignisgesteuerten Prozessketten heraus. Im Anschluss wurde eine empirische Befragung vorgestellt. Dabei wurden die Fragen detailliert beschrieben und die Ergebnisse erläutert. 29

30 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 als Swimlane-Diagramme dargestellt werden können. Zunächst wird aber die Darstellungsvariante vorgestellt, die für diese Regeln und Algorithmen als Grundlage dient Verwendete Variante Die Ergebnisse der empirischen Untersuchung haben gezeigt, dass Variante 3 und 4 (Abschnitt 4.3.1) eine große Akzeptanz gefunden haben. Aus diesem Grund und durch die semantischen Unklarheiten von Variante 1 wird daher Variante 3 als Basis für die hier beschriebene Swimlane-Darstellung genommen. Abbildung 5.1.: Verwendete Variante Um die zeitliche Komponente und die Einhaltung der Syntax zu gewährleisten, werden die Ereignisse, welche zur gleichen Zeit auftreten - also z.b. gleiche Ereignisse, die in mehreren Swimlanes vorkommen -, mit einer Kante verbunden. Abbildung 5.1 soll dieses Vorgehen verdeutlichen. 30

31 5. Darstellung von Swimlanes in Ereignisgesteuerten Prozessketten 5.2. Regeln An dieser Stelle sollen nun einige Regeln aufgestellt werden, welche dann später in den Algorithmen zum Aufbau von Swimlanes angewandt werden. Im Folgenden werden solche Swimlane-Diagramme, die nach Organisationseinheiten aufgebaut sind, als Organisations-Swimlane-Diagramme (kurz: OSD) bezeichnet. Hingegen werden Swimlane-Diagramme, die nach Informationsobjekten aufgebaut sind, Informations-Swimlane-Diagramme (kurz: ISD) genannt Grundlegende Regeln Anwendungen bzw. unterstützende 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 Swimlane mit dem Namen undefiniert, zu welcher diese Funktionen zugeordnet werden. Gibt es in ISDs Funktionen, bei denen kein Informationsobjekt angegeben ist, existiert eine Swimlane mit dem Namen unabhängig, zu welcher diese Funktionen zugeordnet werden. In OSDs bleiben Symbole für Informationsobjekte erhalten. In ISDs bleiben Symbole für Organisationseinheiten erhalten. In ISDs werden die Richtungen der Datenflüsse mittels Pfeilen für Input und Output gekennzeichnet 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 Funktion mit ihrem Vorgänger- und Nachfolgerereignis in die jeweilige Swimlane verschoben. Diesen Sachverhalt zeigt Abbildung 5.2. Abbildung 5.2.: Funktion mit einer Organisationseinheit 31

32 5. Darstellung von Swimlanes in Ereignisgesteuerten Prozessketten Funktion mit mehreren Organisationseinheiten Abbildung 5.3 zeigt das Vorgehen bei Funktion mit mehreren Organisationseinheiten. Da mehrere Organisationseinheiten an einer Funktion bedeutet, dass sie parallel an einer Aufgabe arbeiten, wird die dargestellte Prozesskette in eine AND-Verknüpfung überführt. Nach dieser Transformation kann dann mit den in Abschnitt vorgestellten Verknüpfungen 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, muss bei ihnen nicht darauf geachtet werden, ob ein anderes Informationsobjekt vorhanden ist. Daher wird hier die Verknüpfnung, wie in Abbildung 5.4 dargestellt, unverändert in die Swimlanes übernommen. Abbildung 5.4.: Funktion mit mehreren Informationsobjekten Verknüpfungen Verknüpfungen haben eine besondere Stellung, da sie semantisch sehr mächtig sind. Aus diesem Grund sollen nun alle, in einer Ereignisgesteuerten Prozesskette möglichen, Verknüpfungen betrachtet werden. Dabei sollen vier Verknüpfungen gesondert betrachtet werden. Ereignis > Funktion AND-Split Bei dieser Verknüpfung wird im Falle von verschiedenen Organisationseinheiten bzw. Informationsobjekten die AND-Verknüpfung aufgelöst und auf die jeweiligen Swimlanes verteilt. Dies kann geschehen, da beide 32

33 5. Darstellung von Swimlanes in Ereignisgesteuerten Prozessketten Funktionen ausgeführt werden müssen. Daher ist es an dieser Stelle für den Betrachter irrelevant, ob und wie der andere Teilnehmer reagiert. Ist nur eine Organisationseinheit bzw. ein Informationsobjekt beteiligt, so kann diese Verknüpfung exakt in die jeweilige Swimlane übernommen werden. Abbildung 5.5.: Ereignis > Funktion AND-Split Funktion > Ereignis AND-Join Wenn an dieser AND-Verknüpfung in einem Organisations-Swimlane-Diagramm mehrere Organisationseinheiten beteiligt sind, so muss in jeder beteiligten Swimlane überprüft werden, ob der bzw. die anderen Beteiligten ihre Aufgaben ausgeführt haben. Aus diesem Grund wird die Verknüpfung wie folgt transformiert. Diese Transformation ist in Abbildung 5.6 dargestellt. Angenommen an dieser Verknüpfung sind die Organisationseinheiten A und B beteiligt. So wird in der Swimlane A ein Ereignis eingeführt, das bestätigt, dass die vorhergehende Funktion bei A ausgeführt wurde. Dieses Ereignis wird mit dem Äquivalent der Swimlane B AND-verknüpft. Zur Einhaltung der Syntax muss eine neue Funktion eingeführt werden. Diese Funktion ist dann eine Dummy- Funktion, das heißt in ihr wird nichts ausgeführt, sie stellt lediglich einen Wartezustand dar. Daher erhält sie die Aufschrift wait for completion. Auf diese Funktion folgt dann das Ereignis, das auf die ursprüngliche AND-Verknüpfung folgte. Abbildung 5.6.: Funktion > Ereignis AND-Join (OSD) Wenn an dieser AND-Verknüpfung in einem Informations-Swimlane-Diagramm mehrere Informationsobjekte beteiligt sind (siehe Abbildung 5.7), so wird diese Verknüpfung getrennt und in die jeweiligen Swimlanes 33

34 5. Darstellung von Swimlanes in Ereignisgesteuerten Prozessketten verteilt. Da Informationsobjekte keine aktiven Elemente sind, sie also nicht selber den Erfolg der Funktion bestimmen können, ist hier keine weitere Behandlung notwendig. Abbildung 5.7.: Funktion > Ereignis AND-Join (ISD) Ist an der ursprünglichen AND-Verknüpfung nur eine Organisationseinheit bzw. ein Informationsobjekt beteiligt, so wird auch diese exakt in die jeweilige Swimlane übernommen. Funktion > Ereignis OR-Join Bei dieser Art von Verknüpfung wird die OR-Verknüpfung wie im Funktion >Ereignis AND-Join behandelt (siehe Abbildung 5.8). Da das folgende Ereignis eintritt wenn entweder eine oder alle Funktionen ausgeführt worden sind, kann es zu semantischen Problemen kommen. So wäre es zum Beispiel möglich, dass die folgende Funktion mehrfach ausgeführt wird, wenn die auslösenden Ereignisse zeitversetzt eintreten. Abbildung 5.8.: Funktion > Ereignis OR-Join Abbildung 5.9.: Funktion > Ereignis OR-Join (ISD) 34

35 5. Darstellung von Swimlanes in Ereignisgesteuerten Prozessketten Wie auch beim Funktion >Ereignis AND-Join, können solche Verknüpfungen in Informations-Swimlane- Diagrammen aufgespaltet und auf die Swimlanes verteilt werden. Ist an dem OR-Join nur eine Organisationseinheit bzw. ein Informationsobjekt beteiligt, so kann er ohne weitere Behandlung in die Swimlane übernommen werden. Funktion > Ereignis XOR-Join Bei dieser Verknüpfung wird auch ähnlich dem Funktion >Ereignis AND-Join vorgegangen. Dabei wird dann anstelle einer AND-Verknüpfung eine XOR-Verknüpfung eingeführt. Der Fall von mehreren Organisationseinheit in einem Organisations-Swimlane-Diagramm wird in Abbildung 5.10 dargestellt. Dabei muss bei dieser XOR-Verknüpfung geprüft werden, ob die anderen Teilnehmer ihre Funktion nicht ausgeführt haben. Auch hier gilt, dass eine Dummy-Funktion eingeführt werden muss. Auf diese folgt dann das ursprüngliche Ereignis. Abbildung 5.10.: Funktion > Ereignis XOR-Join (OSD) Tritt solch eine XOR-Verknüpfung in Informations-Swimlane-Diagrammen auf, so wird sie aufgeteilt und in die 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 Änderung in die jeweilige Swimlane übertragen. 35

36 5. Darstellung von Swimlanes in Ereignisgesteuerten Prozessketten weitere Verknüpfungen Da an den weiteren Verknüpfungen, wie sie in Tabelle 5.1 dargestellt sind, immer nur eine Funktion beteiligt ist, können diese direkt in die jeweiligen Swimlanes übertragen werden. Ereignis > Funktion Funktion > Ereignis AND-Join AND-Split OR-Join OR-Split XOR-Join XOR-Split Tabelle 5.1.: weitere Verknüpfungen 5.3. Vorgehen Nun werden Vorgehensweisen vorgestellt, mit Hilfe derer vorhandene Ereignisgesteuerte Prozessketten als Swimlane-Diagramme dargestellt werden können. Im Anschluss wird gezeigt, wie neue Ereignisgesteuerte Prozessketten in Swimlanes aufgebaut werden. Transformation von vorhandenen EPKs in Organisations-Swimlane-Diagramme Im Folgenden wird davon ausgegangen, dass eine fertig modellierte Ereignisgesteuerte Prozesskette vorhanden ist, welche in ein Organisations-Swimlane-Diagramm transformiert werden soll. Das Vorgehen beim Erstellen von neuen EPKs wird in einem späteren Abschnitt beschrieben. Zu Beginn wird für jede Organisationseinheit eine Swimlane angelegt. Existieren Funktionen, denen kei- 36

37 5. Darstellung von Swimlanes in Ereignisgesteuerten Prozessketten ne Organisationseinheit zugeordnet ist, wird eine zusätzliche Swimlane mit dem Titel undefiniert erstellt. Mit Hilfe dieser Swimlane kann überprüft werden, ob die EPKs semantisch korrekt sind. In der fertigen Swimlane-Darstellung sollte keine Swimlane undefiniert mehr existieren, da einer Funktion semantisch immer mindestens eine Organisationseinheit oder ein IT-System zugeordnet ist. Wurden die Swimlanes angelegt, so kann begonnen werden die Elemente in die jeweiligen Swimlanes zu verschieben. Dazu werden alle Funktionen in die Swimlane zu ihrer Organisationseinheit verschoben bzw. - im Falle von mehreren teilnehmenden Organisationseinheiten - kopiert. Ist an einer Funktion keine Organisationseinheit angegeben, so wird diese in der Swimlane undefiniert abgelegt. Zu diesen Funktionen werden dann die anderen zugehörigen Elemente anhand der Regeln aus Abschnitt 5.2 hinzugefügt. Die Symbole für Organisationseinheiten entfallen in der Swimlane-Darstellung komplett. Symbole für Informationsobjekte bleiben allerdings weiterhin erhalten. Da die vertikale Achse der Swimlane die Zeit repräsentiert, werden alle Elemente, die gleich sind, und jene, die zur gleichen Zeit stattfinden, auf der gleichen gedachten horizontalen Linie gezeichnet. Ereignisse, auf die dies zutrifft, werden zusätzlich mit Linien verbunden. Dieses sind die einzigen Linien in EPK-Swimlane-Diagrammen, die die Grenzen einer Swimlane überschneiden können. Transformation von vorhandenen EPKs in Informations-Swimlane-Diagramme Nun soll das Vorgehen beim Transformieren in ein Informations-Swimlane-Diagramm beschrieben werden. Allgemein verfährt man bei dieser Transformation wie bei Organisations-Swimlane-Diagrammen. Anstatt der Organisationseinheiten werden hier die Informationsobjekte betrachtet. So wird für Funktionen, an denen kein Informationsobjekt beteiligt ist, keine Swimlane undefiniert erstellt, sondern eine Swimlane unabhängig. In der Semantik von Ereignisgesteuerten Prozessketten müssen an Funktionen nicht zwangsläufig Informationsobjekte beteiligt sein. Diese Swimlane kann auch in fertigen ISDs erhalten bleiben. Wichtig bei dieser Darstellung ist, dass hier teilsweise andere Regeln gelten, als bei OSDs. Die Symbole für Informationsobjekte entfallen in dieser Darstellung. Symbole für Organisationseinheiten bleiben jedoch erhalten. Um den Datenfluss der Informationsobjekte zu kennzeichnen, werden Pfeile zu bzw. von den Funktionen weg eingezeichnet gezeichnet. Diese Pfeile werden zusätzlich mit einer Aufschrift für Input und Output versehen. Ist ein Informationsobjekt ein Input für die Funktion, so zeigt der Pfeil zur Funktion hin. Ist es hingegen ein Output, so zeigt der Pfeil von der Funktion weg. Ist das Informationobjekt sowohl 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 Möglichkeiten. Entweder man baut sie in der klassischen Darstellung auf und geht dann mit den oben beschrieben Methoden vor oder man stellt die EPKs direkt in Swimlanes dar. Dazu beginnt man zeitlich mit der ersten Funktion und legt für die an dieser Funktion beteiligten Organisationseinheiten bzw. Informationsobjekte Swimlanes an. In diese Swimlanes wird die Funktion und das vorhergehende Ereignis und evtl. der vorhergehende Prozesswegweiser in die neu angelegten Swimlanes gezeichnet. Nun kann nach den oben vorgestellten Regeln fortgefahren werden. Dabei ist wichtig, dass für jede neu hinzukommende Organisationseinheit bzw. jedes Informationsobjekt eine neue Swimlane erstellt wird. 37

38 5. Darstellung von Swimlanes in Ereignisgesteuerten Prozessketten 5.4. Beispiel-Transformation Nun wird eine Beispiel-EPK vorgestellt, die mit den in den letzten Abschnitten vorgestellten Regeln und Vorgehensweisen in ein Swimlane-Diagramm transformiert wird. Diese Ereignisgesteuerte Prozesskette beschreibt die allabendliche Kassenabrechnung eines Supermarktes (siehe Abbildung 5.12). Dabei sind die drei Organisationseinheiten Kassiererin, Hauptkassiererin und Marktleiter, sowie die Anwendung Kassensystem beteiligt. Abbildung 5.12.: Beispiel einer manuellen Transformation: EPK in klassischer Darstellung 38

39 5. Darstellung von Swimlanes in Ereignisgesteuerten Prozessketten Schritt 1 Abbildung 5.13.: Beispiel einer manuellen Transformation (Schritt 1) Funktionen mit mehreren Organisationseinheiten werden aufteilen. 39

40 5. Darstellung von Swimlanes in Ereignisgesteuerten Prozessketten Schritt 2 Abbildung 5.14.: Beispiel einer manuellen Transformation (Schritt 2) Für jede Organisationseinheit wird eine Swimlane angelegt. Daraufhin werden die Funktionen mit Vorgänger- und Nachfolgerereignissen und eventuellen Verknüpfungen auf die jeweilige Swimlanes verteilt. 40

41 5. Darstellung von Swimlanes in Ereignisgesteuerten Prozessketten Schritt 3 Abbildung 5.15.: Beispiel einer manuellen Transformation (Schritt 3) Die Verknüpfungen werden nach den in Abschnitt dargestellten Regeln behandelt. 41

42 5. Darstellung von Swimlanes in Ereignisgesteuerten Prozessketten Schritt 4 Abbildung 5.16.: Beispiel einer manuellen Transformation (Schritt 4) Im letzten Schritt werden gleiche Ereignisse mit einer Linie verbunden. 42

43 5. Darstellung von Swimlanes in Ereignisgesteuerten Prozessketten 5.5. Zusammenfassung In diesem Kapitel wurde zu Beginn die endgültig verwendete Variante einer Swimlane-Darstellung beschrieben. 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 Vorgehen anhand einer Beispiel-Transformation praktisch gezeigt. 43

44 6. Implementierung 6. Implementierung In diesem Kapitel soll nun die Implementierung einer Visualisierung von Swimlanes in Ereignisgesteuerten Prozessketten beschrieben werden. Zu diesem Zweck wurde ein Plug-In mit dem Namen LaneEPC für die Entwicklungsumgebung Eclipse entwickelt. Dieses Plug-In basiert wiederum auf dem vom Fachgebiet Software Engineering der Leibniz Universität Hannover zur Verfügung gestellten Plug-In ProFLOW. Im folgenden Abschnitt werden LaneEPC und die zugrundeliegenden Architekturen beschrieben Zugrundeliegende Architekturen Eclipse und das Graphical Editing Framework (GEF) Eclipse ist eine Java-basierte Entwicklungsumgebung [Thea]. Durch die Portabilität von Java ist sie für viele Plattformen verfügbar. Über die reine Anwendungsentwicklung hinaus, bietet Eclipse die Möglichkeit Plug- Ins zu entwickeln, wodurch eine Vielzahl von neuen Funktionen der Entwicklungsumgebung hinzugefügt werden können. So ist es zum Beispiel durch das Graphical Editing Framework (GEF) möglich, grafische Editoren und Views der Workbench hinzuzufügen [Thec]. Damit können dann nicht nur Texte bearbeitet, sondern auch Diagramme gezeichnet werden. Beim Schreiben dieser Arbeit lagen sowohl Eclipse als auch GEF in der Version 3.2 vor ProFLOW ProFLOW ist ein Plug-In-Feature für Eclipse, mit dem Flussdiagramme gezeichnet werden können. Dabei stehen in der vorliegenden Version in Verbindung mit GEF Mechanismen zur Zeichnung von UML- Aktivitätsdiagrammen und erweiterten Ereignisgesteuerten Prozessketten zur Verfügung. Darüber hinaus bietet es eine eigene Plug-In-Struktur, die es ermöglicht, mit wenigen Schritten beliebige Prozesstypen hinzuzufügen. Dazu müssen lediglich für die einzelnen Elemente des neuen Prozesses die Modellklassen, Objektdarstellungen, 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.core im MVC-Pattern [Maj04] für das Model und für weitere Kernoperationen, wie z.b. Dateizugriffe, zuständig. Hingegen regelt ProFLOW.ui View und Controller. Das Plug-In ProFLOW.activity stellt den Diagrammtyp für UML-Aktivitätsdiagramme zur Verfügung. Schlussendlich ist dann im Plug-In ProFLOW.eepk alles Notwendige zum Modellieren von Ereignisgesteuerten Prozessketten enthalten LaneEPC LaneEPC ist nun das in dieser Arbeit entwickelte Plug-In für Eclipse. Dabei basiert es auf ProFLOW, stellt aber keinen neuen Prozesstyp dar. Vielmehr wird es verwendet, um Ereignisgesteuerte Prozessketten, welche in ProFLOW modelliert worden sind, in Swimlanes darzustellen. Dazu wird der Prozess nach dem Einlesen von einem Transformator behandelt, der ihn in eine Swimlane-Darstellung umwandelt. Dieser Transformator wird in Abschnitt 6.3 ausführlich erläutert. 44

45 6. Implementierung Zunächst soll aber das Verhältnis der Plug-Ins zueinander und die Struktur eines Swimlane-Diagramms in LaneEPC beschrieben werden. Im Anschluss daran wird kurz auf Benutzerinteraktionen eingegangen Verhältnis zwischen den Plug-Ins Abbildung 6.1.: Das Verhältnis der Plug-Ins untereinander Abbildung 6.1 verdeutlicht das Verhältnis zwischen LaneEPC und den beteiligten ProFLOW-Plug-Ins. Ein ProFLOW-Prozesstyp-Plug-In, zum Beispiel gegeben durch das Plug-In ProFLOW.eepk, enthält Model, View und Controller aller dazugehörigen Elemente. Dieser Prozesstyp muss in der Form auf der Ereignisgesteuerten Prozesskette basieren, dass EPK-Elemente, wie Ereignisse und Funktionen, definiert werden. Dabei verwendet er die jeweiligen Mechanismen aus ProFLOW.core und ProFLOW.ui. LaneEPC benutzt wiederum die Elemente und Funktionalitäten, die vom Prozesstyp zur Verfügung gestellt werden. Darüber hinaus werden neue Elemente auf Basis von ProFLOW.core und ProFLOW.ui implementiert, wie zum Beispiel Model und View einer Swimlane oder einer Syncronisationslinie Interne Struktur Abbildung 6.2.: Plug-In-Struktur 45

46 6. Implementierung Wie Abbildung 6.2 zeigt, wird beim Start von LaneEPC ein LaneEPCEditor geöffnet. Dieser erhält einen Prozess von dem mit ProFLOW gelieferten XMLImporter. Der XMLImporter liest eine Datei im ProFLOW-Format ein. In dieser Datei ist der Prozesstyp als ID gespeichert. Mittels dieser ID sucht der aus ProFLOW stammende ExtensionPointManager das zugehörige Prozessobjekt, in welches die in der Datei enthaltenen Daten gespeichert 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 für diesen Prozess möglichen Diagrammtypen und bietet diese dem Benutzer als Auswahl an. Mit der Benutzerwahl bekommt der Editor wiederum aus dem ExtensionPointManager das zu diesem Diagrammtyp gehörende Transformatorobjekt. An dieses Transformatorobjekt wird der Prozess übergeben und umgewandelt. Das Transformatorobjekt muss dabei von der Klasse CommonTransformator abgeleitet sein. Im Plug-In LaneEPC sind bereits zwei Transformatoren für Ereignisgesteuerte Prozessketten aus dem Plug- In ProFLOW.eepk enthalten. Dabei implementiert ein Transformator die Transformation von Ereignisgesteuerten Prozessketten in Organisations-Swimlane-Diagramme (EEPKOSDTransformator) und ein weiterer in Informations-Swimlane-Diagramme (EEPKISDTransformator). Auf diese Transformatoren beziehen sich die folgenden Abschnitte. Abbildung 6.3.: Metamodell eines Swimlane-Diagramms Abbildung 6.3 zeigt das Metamodell einer Ereignisgesteuerten Prozesskette aus ProFLOW.eepk in einem Swimlane-Diagramm, wie es von LaneEPC verwendet wird. Der Swimlane-Prozess ist der Prozess, der von GEF und ProFLOW angezeigt wird. Dieser enthält mindestens eine Swimlane. Eine Swimlane wiederum enthält die Verknüpfungselemente AND, OR und XOR aus ProFLOW.core und Ereignis- und Funktionselemente aus ProFLOW.eepk. 46

47 6. Implementierung Funktionen werden in Swimlanes zusätzlich Annotationen angefügt. In Organisations-Swimlane-Diagrammen sind dies Input- und Outputobjekte für Informationsobjekte. Bei Informations-Swimlane-Diagrammen werden neben Organisationseinheiten sogenannte ISD-Elemente verwendet. Die ISD-Elemente Input, Output und In-/Output stellen die Richtungen des Datenflusses dar. Dagegen werden Independent-Objekte an die Funktion angefügt, die in der unabhängig -Swimlane stehen, da an diesen keine Richtung verzeichnet werden kann Benutzerinteraktion LaneEPC kann gestartet werden, indem im Package Explorer von Eclipse mit der rechten Maustaste auf eine bestehende ProFLOW-Datei geklickt und Open with und LaneEPC ausgewählt wird. Gibt es für den Prozesstyp dieser Datei nur einen Diagrammtyp, so wird dieser geöffnet. Wenn es mehrere Diagrammtypen gibt, erscheint ein Auswahlfenster, aus dem der gewünschte Typ ausgewählt werden kann. Gibt es dagegen keinen Diagrammtyp, so wird eine Fehlermeldung angezeigt. Wird ein Organisations-Swimlane-Diagramm für einen ProFLOW.eepk-Prozess angezeigt, können Funktionen, die sich in der undefiniert -Swimlane befinden, mit Rechtsklick auf diese und der Auswahl von Move undefined Function in eine andere Swimlane verschoben werden. Diese Aktion passt den ursprünglich eingelesenen Prozess an, wodurch diese Änderung dann - nach Speicherung - auch in ProFLOW verfügbar sind Transformator Ein Transformator wandelt einen eingelesenen Prozess in eine Swimlane-Darstellung um und gibt ihn hinterher an den Editor zurück der ihn dann anzeigt. Im Folgenden werden die Schritte der in LaneEPC integrierten Transformatoren von ProFLOW.eepk-Prozessen in OSDs und ISDs vorgestellt. Wie Transformatoren für andere Prozess- oder Diagrammtypen implementiert werden können, wird in Abschnitt beschrieben. Zuerst werden die Funktionen des eingegebenen Prozesses durchlaufen. Dabei wird nach solchen gesucht, die im Falle von Organisations-Swimlane-Diagrammen keine Organisationseinheiten und im Falle von Informations-Swimlane-Diagrammen keine Informationsobjekte enthalten. Diesen Funktionen wird dann eine Organisationseinheit mit der Bezeichnung undefiniert bzw. ein Informationsobjekt mit der Bezeichnung unabhängig angehängt. Im nächsten Schritt werden alle Funktionen behandelt, an denen mehr als eine Organisationseinheit bzw. ein Informationsobjekt verzeichnet sind. Diese werden dann nach der Regel in Abschnitt aufgesplittet. Der Einfachheit halber wird diese Regel auch bei ISDs angewandt, so müssen mehrere Informationsobjekte später nicht gesondert behandelt werden. Nachdem nun an jeder Funktion in OSDs genau eine Organisationseinheit bzw. in ISDs genau ein Informationsobjekt verzeichnet ist, können alle Beteiligten gesucht werden. Diese Liste aller Beteiligten wird nun benutzt, um die jeweiligen Swimlanes anzulegen. Dabei werden die Swimlanes so sortiert, dass die Swimlane undefiniert in OSDs ganz links steht und die Swimlane unabhängig in ISDs ganz rechts steht. Dies geschieht, damit in OSDs Inkonsistenzen in der Modellierung sofort sichtbar sind, da, wie bereits beschrieben, in OSDs keine Funktionen ohne Organisationseinheiten existieren sollten. Im nächsten Schritt werden nun die Elemente auf die zugehörigen Swimlanes verteilt. Dabei wird jede Funktion einzeln behandelt. Sie und ihre Vorgänger- und Nachfolgerereignisse, inklusive eventueller Verknüpfungen, werden in die jeweilige Swimlane geschrieben. 47

48 6. Implementierung Sind nun alle Funktionen verteilt, werden auf die in den Swimlanes vorhandenen Verknüpfungen die in Abschnitt vorgestellten Regeln angewandt. Im Anschluss daran werden alle gleichen Ereignisse, die in mehreren Swimlanes vorkommen, mit einer sogenannten Syncronisationslinie miteinander verbunden. Enthalten nun alle Swimlanes ihre Elemente, müssen diese noch positioniert werden. Dazu wird erst eine vertikale Positionierung vorgenommen, bei welcher die Koordinaten der Elemente mit ihren Nachbarswimlanes abgeglichen werden, um die zeitliche Komponente zu gewährleisten. Danach wird eine horizontale Positionierung vorgenommen. Dabei wird für jede Swimlane versucht, die bestmögliche 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 übergeben und von GEF und ProFLOW gezeichnet Erweiterungsmöglichkeiten Das Ziel der Implementierung dieser Bachelorarbeit ist eine Visualisierung von Swimlanes in Ereignisgesteuerten Prozessketten. Hier sollen nun Erweiterungsmöglichkeiten für LaneEPC vorgestellt werden, die über dieses Ziel hinausgehen, aber dennoch in Zukunft interessant sein könnten Weitere Diagrammtypen und weitere EPK-basierte Prozesstypen In letzter Zeit kristallisieren sich immer mehr Prozesstypen heraus, die auf Ereignisgesteuerten Prozessketten basieren. Als Beispiel dafür kann man die in der Masterarbeit von Sebastian Intas [Int06] vorgestellte Ereignisgesteuerte Prozesskette für Webservices nennen. LaneEPC bietet zu diesem Zweck die Möglichkeit, Plug-Ins zu schreiben, die neue Diagrammtypen definieren. Dazu muss in diesem lediglich eine Extension auf LaneEPC.diagram erstellt werden. In dieser werden die 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 eingefügt werden. undefinedclass - Die Klasse der Annotation, mit welcher undefinedname angefügt wird. Desweiteren muss ein Transformator - als Singleton-Klasse - geschrieben werden, der CommonTransformator erweitert. In diesem werden Funktionen zur Verarbeitung von Verknüpfungen (handleconnectors()), zur Sortierung der Swimlanes bzw. Liste der Beteiligten (sortlistofparticipants()), falls notwendig zum Ersetzen von Annotationen (replaceannotation())und folgende Getter und Funktionen zum Validieren und Erstellen von Elementen implementiert: getdiagramid() - Gibt die ID des Diagrammtypes zurück. gettransitiontype() - Gibt den Transitionstyp zurück. isvalidfunction(element element) - Überprüft, ob element eine Funktion ist. 48

49 6. Implementierung isvalidevent(element element) - Überprüft, ob element ein Ereignis ist. isvalidconnector(element element) - Überprüft, ob element eine Verknüpfung ist. isvalidannotation(annotation annotation) - Überprüft, ob annotation eine Annotation ist, nach der die 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-Verknüpfung. (Benötigt für die Aufsplittung von mehreren 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 Möglichkeit gegeben, über den Extension Point LaneEPC.action Aktionen zu definieren, die speziell auf einen Diagrammtyp angewendet werden können. So können die Aktionen, wie in ProFLOW üblich, über ProFLOW.ui.processActions und ProFLOW.ui.modelObjectActions oder LaneEPC.action, unter der Angabe eines Diagrammtyps, eingetragen werden Editorenfenster In Eclipse gibt es die Möglichkeit, Editorenfenster mit mehreren Arbeitsflächen zu öffnen. Zwischen diesen Arbeitsflächen kann dann mittels Registerkarten gewechselt werden. So könnte man sich vorstellen, dass, wenn eine ProFLOW-Datei geöffnet wird, auf einer Registerkarte der Standard-ProFLOW-Editor und auf weiteren Registerkarten die Darstellungen für die Diagrammtypen, die für diesen Prozess verfügbar sind, angezeigt wird. Um dies zu realisieren, muss die Editor-Klasse in ProFLOW.ui angepasst, bzw. ersetzt werden. Weitere Informationen hierzu finden sich in der API von Eclipse [Theb] Verschiebung und Skalierung von Elementen ProFLOW unterstützt in der vorliegenden Version keine Containerelemente, welche allerdings für die Swimlanes zwingend notwendig sind. Containerelemente sind Elemente, die andere Elemente beinhalten können. Die Swimlanes wurden hier provisorisch als Containerelemente implementiert. Allerdings sind im Moment noch keine Benutzerinteraktionen möglich, die sich auf das Verschieben und Skalieren von Elementen innerhalb einer Swimlane beziehen. Aus diesem Grund wurde eine automatische Positionierung der Elemente implementiert. Dies kann aber keine endgültige Lösung sein, da ein Benutzer in vielen Fällen sein Diagramm von Hand anpassen möchte. Dies sollte dann mit kleinen Anpassungen möglich sein, wenn Containerelemente in ProFLOW fertiggestellt sind. Dazu müssen lediglich die EditPolicies für die Swimlane-Elemente eingerichtet werden EPK-Elemente ProFLOW.eepk unterstützt aktuell nicht alle Elemente einer Ereignisgesteuerten Prozesskette. So sind im Moment noch keine Prozesswegweiser und keine Anwendungssysteme implementiert. Wenn diese fertiggestellt sind, müssen in den jeweiligen Transformatoren nur die beiden Funktionen isvalidannotation() und isvalidevent() angepasst werden. 49

50 6. Implementierung EPML In Abschnitt 2.5 wurde der XML-Dialekt EPML vorgestellt. Man könnte sich nun gut vorstellen, EPML als alternative Dateiquelle für Ereignisgesteuerte Prozessketten zu verwenden. Dazu würde, parallel zu dem in ProFLOW integrierten XMLImporter, ein EPML-Importer implementiert werden, der EPML-Dateien ausliest und daraus Prozesse erstellt. EPML und das ProFlow-Dateiformat sind sich sehr ähnlich, daher sollten keine umfangreichen Änderungen gegenüber dem XMLImporter vorgenommen werden müssen. Durch das EPML- Format wären auch Hierarchien in Ereignisgesteuerten Prozessketten (siehe Abschnitt 2.2.2) möglich Zusammenfassung In diesem Kapitel wurde die Implementierung einer Visualisierung von Swimlanes in Ereignisgesteuerten Prozessketten vorgestellt. Dazu wurden die zugrundeliegenden Architekturen beschrieben. Darauf folgend wurde LaneEPC erläutert. Es wurde das Verhältnis zu den ProFLOW-Plug-Ins dargestellt und auf die interne Struktur von LaneEPC, sowie die Benutzerinteraktionen eingegangen. Im Anschluss wurden die Transformatoren für ProFLOW.eepk vorgestellt. Zum Ende dieses Kapitels wurden dann ausführlich diverse Erweiterungsmöglichkeiten beschrieben. 50

51 7. Beispiel 7. Beispiel In diesem Kapitel werden zwei Beispiele für Swimlane-Diagramme in ProFLOW gegeben. Dazu wird jeweils zuerst die Darstellung in ProFLOW und danach in LaneEPC gezeigt. Die Ereignisgesteuerte Prozesskette welche hier als Organisations-Swimlane-Diagramm dargestellt ist, handelt von der Leergutannahme in einem Supermarkt mit den Beteiligten Kunde und Mitarbeiter. Das Beispiel für Informations-Swimlane-Diagramme zeigt wiederum das aus Abschnitt bekannte Beispiel eines Kopiervorgangs von Datenbanktabellen. 51

52 7. Beispiel 7.1. Organisations-Swimlane-Diagramm Beispiel OSD - ProFLOW Abbildung 7.1.: Beispiel für OSD: EPK in ProFLOW 52

53 7. Beispiel Beispiel OSD - LaneEPC Abbildung 7.2.: Beispiel für OSD: EPK in LaneEPC 53

54 7. Beispiel 7.2. Informations-Swimlane-Diagramm Beispiel ISD - ProFLOW Abbildung 7.3.: Beispiel für ISD: EPK in ProFLOW 54

55 7. Beispiel Beispiel ISD - LaneEPC Abbildung 7.4.: Beispiel für ISD: EPK in LaneEPC 55

56 8. Zusammenfassung und Ausblick 8. Zusammenfassung und Ausblick Ziel dieser Arbeit war es, den aus UML und BPML bekannten Begriff der Swimlanes auf Ereignisgesteuerte Prozessketten zu übertragen. Dazu sollte ein Konzept aufgestellt werden, mit dem es möglich ist, Ereignisgesteuerte Prozessketten aus der klassischen Darstellung in eine Swimlane-Darstellung zu transformieren. Die Resultate dieses Konzepts sollten zur Visualisierung in einem Plug-In für die Entwicklungsumgebung Eclipse realisiert werden. Das zweite Kapitel erläuterte dazu alle, für das Konzept nötigen, Grundlagen. Es wurden Geschäftsprozesse in Verbindung mit serviceorientierten Architekturen gebracht, worauf sich dann die Notwendigkeit für die Ereignisgesteuerte Prozesskette begründete. Diese wurde mit ihren Elementen vorgestellt. Der folgende Abschnitt führte in die Idee, die hinter Swimlanes steht, ein und visualisierte sie an einem Beispiel in UML- Aktivitätsdiagrammen. Nun galt es, das XML-Schema der Event-Driven-Process-Chain-Markup-Language (EPML) vorzustellen, welche langsam zum Standard-Austauschformat für Ereignisgesteuerte Prozessketten wird. Kapitel 3 beschäftigte sich mit einer Gegenüberstellung von Ereignisgesteuerten Prozessketten und UML- Aktivitätsdiagrammen. Dazu wurde UML kurz vorgestellt, worauf im Anschluss UML-Aktivitätsdiagramme mit der Ereignisgesteuerten Prozesskette verglichen worden sind. Im vierten Kapitel wurde dann in das auszuarbeitende Konzept eingeführt. Dabei wurde der Nutzen von Swimlanes herausgestellt. Anhand einer empirischen Befragung wurden im Folgenden erste Anregungen zum Konzept validiert. Hierzu stellte es den verwendeten Fragebogen ausführlich vor. Das 5. Kapitel beschäftigte sich mit Regeln und Vorgehensweisen zum Transformieren von Ereignisgesteuerten Prozessketten in eine Swimlane-Darstellung. Eine Beispieltransformation zeigte dann am Ende, wie diese Transformation Schritt für Schritt abläuft. Kapitel 6 stellte die Implementierung einer Visualisierung von Swimlanes in Ereignisgesteuerten Prozessketten vor. Dazu wurden die grundlegenden Architekturen beschrieben und mit einer Beschreibung des entwickelten Plug-Ins LaneEPC verknüpft. Dazu wurde der Transformator vorgestellt, der die EPK in ein Swimlane-Diagramm umwandelt. Den Abschluss dieses Kapitels machte dann eine Beschreibung, wie LaneEPC erweitert werden könnte. Nachdem in Kapitel 6 die Implementierung dargestellt wurde, wurden in Kapitel 7 jeweils ein Beispiel für ein Organisations-Swimlane-Diagramm und ein Informations-Swimlane-Diagramm in LaneEPC vorgestellt. Als Fazit für diese Arbeit lässt sich sagen, dass das Konzept die geforderten Ziele erfüllt. Es wurden Regeln zur Transformation von Ereignisgesteuerten Prozessketten in eine Swimlane-Darstellung aufgestellt und der Nutzen dafür erläutert. Insgesamt kann man sagen, dass Swimlanes in Ereignisgesteuerten Prozessketten eine erhebliche Erleichterung, insbesondere für den Betrachter, darstellen. 56

57 8. Zusammenfassung und Ausblick Je nach Komplexität des Prozesses können aber durchaus große Diagramme entstehen. Werden relativ kleine Prozesse mit wenigen beteiligten Organisationseinheiten oder Informationsobjekten verwendet, ist zu erwägen, ob die klassische Darstellung nicht die bessere Wahl wäre. Sind allerdings viele Organisationseinheiten bzw. Informationsobjekte in einem Prozess beteiligt, so sollte die Swimlane-Darstellung bevorzugt werden Ausblick Es gibt mittlerweile viele Konzepte, die sich mit der Erweiterung von Ereignisgesteuerten Prozessketten befassen, um sie für spezielle Anwendungsfälle anzupassen. So zum Beispiel werden häufig Attribute den Funktionen einer EPK hinzugefügt. Nun kann man sich vorstellen, dass diese Attribute auch in einer Swimlane- Darstellung verarbeitet werden. Wird etwa als Attribut der Ort der Ausführung einer Funktion angegeben, so könnten 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 Annotationen aus. Damit bedeuten mehrere Organisationseinheiten an einer Funktion nicht zwangsläufig, dass diese parallel an einer Aufgabe arbeiten. Es bietet vielmehr eine Unterscheidung zwischen paralleler, sequentieller, gemeinsamer und alternativer Bearbeitung einer Funktion. Für diese Änderungen könnten neue Regeln zur Transformation aufgestellt werden. Desweiteren werden in [FL02] Refactoring-Mechanismen für Ereignisgesteuerte Prozessketten vorgestellt, wobei neue Verknüpfungen eingeführt werden. Für diese Verknüpfungen würden auch neue Regeln gelten. Die Bedingungen, die mit diesen Verknüpfungen verbunden sind, werden hier in Matrizen abgeprüft. Es könnte somit ein Konzept ausgearbeitet werden, dass diese Bedingungen automatisiert oder teilautomatisiert verarbeit und anhand dessen Regeln zur Darstellung in einem Swimlane-Diagramm aufgestellt werden. 57

58 Literaturverzeichnis Literaturverzeichnis [BDFK03] [Boo01] [BRJ99] [Dan99] Becker, Jörg, Patrick Delfmann, Thorsten Falk und Ralf Knackstedt: Multiperspektivische ereignisgesteuerte Prozessketten. In: Nüttgens, Markus und Frank J. Rump (Hrsg): EPK Geschäftsprozessmanagement mit Ereignisgesteuerten Prozessketten, Proceedings des GI-Workshops und Arbeitskreistreffens, S , Bamberg, Oktober Booker, Glenn: Process Definition Overview. In: CSC Papers competition 2002, Philadelphia, August Computer Sciences Corporation. Verfügbar unter: edu/~grb25/pubs.html. Booch, Grady, Jim Rumbaugh und Ivar Jacobson: Das UML-Benutzerhandbuch. Professionelle Softwareentwicklung. Addison Wesley Longman Verlag GmbH, München, Dandl, Jörg: Objektorientierte Prozeßmodellierung mit der UML und EPK. In: Schwickert, Axel C. (Hrsg): Arbeitspapiere WI, Nummer 12, Lehrstuhl für Allg. BWL und Wirtschaftsinformatik, Universität Mainz, [FL02] Fettke, Peter und Peter Loos: Refactoring von Ereignisgesteuerten Prozessketten. In: Nüttgens, Markus und Frank J. Rump (Hrsg): EPK Geschäftsprozessmanagement mit Ereignisgesteuerten Prozessketten, Proceedings des GI-Workshops und Arbeitskreistreffens, Trier, November [FvL03] [Ged] Frank, U. und B. L. van Laak: Anforderungen an Sprachen zur Modellierung von Geschäftsprozessen. In: Arbeitsberichte des Instituts für Wirtschaftsinformatik, Band 34, Januar Arbeitsberichte des Instituts für Wirtschaftsinformatik. Gedilan Consulting GmbH: Nautilus - Prozessmanagment. Verfügbar unter: gedilan.com/prozessmanagement_software/index.php. [GRvdA05] Gottschalk, Florian, Michael Rosemann und Wil M.P. van der Aalst: My own process: Providing dedicated views on EPCs. In: Nüttgens, Markus und Frank J. Rump (Hrsg): EPK Geschäftsprozessmanagement mit Ereignisgesteuerten Prozessketten, Proceedings des GI-Workshops und Arbeitskreistreffens, Hamburg, Dezember [Int06] [Jec] [KNS92] [Lar] Intas, Sebastian: Konzept für die Einbindung von Webservices in Ereignisgesteuerte Prozessketten. Masterarbeit, Fachgebiet Software Engineering, Leibniz Universität Hannover, Hannover, Juli Jeckle, Mario: UML auf gut Deutsch. Verfügbar unter: Keller, Gerhard, Markus Nüttgens und August-Wilhelm Scheer: Semantische Prozessmodellierung auf der Grundlage Ereignisgesteuerter Prozessketten (EPK). In: Scheer, A.-W. (Hrsg): Veröffentlichungen des Instituts für Wirtschaftsinformatik (IWi), Universität des Saarlandes, Heft 89, Saarbrücken, Larsson, Alexander: Dia Diagrammeditor. Verfügbar unter: 58

59 Literaturverzeichnis [LGS05] Lübke, Daniel, Jorge Marx Gomez und Kurt Schneider: Serviceorientierte Architekturen und Prozessmanagement. Nummer 3/2005 in ERP Management. GITO Verlag mbh, [Lüb06] Lübke, Daniel: Transformation of Use Cases to EPC Models. In: Nüttgens, Markus, Frank J. Rump und Jan Mendling (Hrsg): EPK Geschäftsprozessmanagement mit Ereignisgesteuerten Prozessketten, Proceedings des GI-Workshops und Arbeitskreistreffens, S , Wien, Dezember [Maj04] Majewski, Bo: A Shape Diagram Editor, Dezember Verfügbar unter: eclipse.org/articles/article-gef-diagram-editor/shape.html. [Mic] Microsoft Corporation: Microsoft Visio. Verfügbar unter: com/de-de/visio/default.aspx. [MN03] [MN05] [NR02] [Obj05] [Soi06] [ST05] [Thea] Mendling, Jan und Markus Nüttgens: Konzeption eines XML-basierten Austauschformates für Ereignisgesteuerte Prozessketten (EPK). In: Informationssystem Architekturen, Wirtschaftsinformatik Rundbrief der GI Fachgruppe WI-MobIS, 10(2003)2, S Gesellschaft für Informatik (GI) e.v., Mendling, Jan und Markus Nüttgens: EPC Markup Language - An XML-Based Interchange Format for Event-Driven Process Chains (EPC). Technischer Bericht, Vienna University of Economics and Business Administration, Wien, März Verfügbar unter: http: //wi.wu-wien.ac.at/home/mendling/publications/tr05-epml.pdf. Nüttgens, Markus und Frank J. Rump: Syntax und Semantik Ereignisgesteuerter Prozessketten (EPK). In: Desel, Jörg und Mathias Weske (Hrsg): Promise Prozessorientierte Methoden und Werkzeuge für die Entwicklung von Informationssystemen, Proceedings des GI-Workshops und Fachgruppentreffens (Potsdam, Oktober 2002), S , Bonn, Object Management Group: UML Superstructure Specification, v2.0 (formal/ ), August Verfügbar unter: Soika, Ralph: BPEL und SOA Architekturen. Imixs Software Solutions GmbH, Verfügbar unter: Scheer, August-Wilhelm und Oliver Thomas: Geschäftsprozessmodellierung mit der Ereignisgesteuerten Prozesskette. In: Das Wirtschaftsstudium 34, Nummer 8-9, S , Saarbrücken, The Eclipse Foundation: Eclipse - an open development platform. Verfügbar unter: http: // [Theb] The Eclipse Foundation: Eclipse SDK - API - Class MultiPageEditorPart. Verfügbar unter: reference/api/org/eclipse/ui/part/multipageeditorpart.html. [Thec] The Eclipse Foundation: Graphical Editing Framework (GEF). Verfügbar unter: http: // [W3C06] W3C: Extensible Markup Language (XML) 1.0 (Fourth Edition), September Verfügbar unter: 59

60 Abbildungsverzeichnis Abbildungsverzeichnis 2.1. Metamodell einer EPK in Anlehung an [Lüb06] Funktion Ereignis Prozesswegweiser eepk-elemente Fallbeispiel Bestellung Darstellung eines UML-Aktivitätsdiagramms in Swimlanes in Anlehnung an [BRJ99] Gegenüberstellung - EPK (links) und UML 2.0 Aktivitätsdiagramm (rechts) Konzept zugrundeliegende EPK Variante 1: Anlehnung an UML-Swimlanes Variante 2: passive Swimlanes Variante 3: Unabhängige Teilprozesse Variante 4: Unabhängige Teilprozesse mit Wartezeitmarkierungen AND-Join-Verknüpfung Möglichkeit Möglichkeit EPK (links) und Swimlane-Diagramm (rechts) Verwendete Variante Funktion mit einer Organisationseinheit Funktion mit mehreren Organisationseinheiten Funktion mit mehreren Informationsobjekten Ereignis > Funktion AND-Split Funktion > Ereignis AND-Join (OSD) Funktion > Ereignis AND-Join (ISD) Funktion > Ereignis OR-Join Funktion > Ereignis OR-Join (ISD) Funktion > Ereignis XOR-Join (OSD) Funktion > Ereignis XOR-Join (ISD) Beispiel einer manuellen Transformation: EPK in klassischer Darstellung Beispiel einer manuellen Transformation (Schritt 1) Beispiel einer manuellen Transformation (Schritt 2) Beispiel einer manuellen Transformation (Schritt 3) Beispiel einer manuellen Transformation (Schritt 4) Das Verhältnis der Plug-Ins untereinander Plug-In-Struktur Metamodell eines Swimlane-Diagramms

61 Abbildungsverzeichnis 7.1. Beispiel für OSD: EPK in ProFLOW Beispiel für OSD: EPK in LaneEPC Beispiel für ISD: EPK in ProFLOW Beispiel für ISD: EPK in LaneEPC Tabellenverzeichnis 2.1. Verknüpfungen weitere Verknüpfungen Listings 2.1. EPML-Elemente als Syntax-Baum

62 A. Fragebogen A. Fragebogen Die folgenden Seiten enthalten den Fragebogen, welcher zur Validierung des Konzeptes dieser Bachelorarbeit verwendet worden ist. 62

63 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 Abbildung 5: Variante 4 Variante 1: Variante 2: Variante 3: Variante 4: Keine Überschneidungen, Swimlanes können einzeln betrachtet werden. wie Variante 1, mit Verbindungspfeilen zur Darstellung von Weiterführungen (Wartezustand) Passive Swimlanes. Der Prozess selbst steht nicht in den Swimlanes sondern nur die Verantwortlichkeiten. Überschneidungen zwischen Swimlanes möglich. Semantisch unklar. Konzept und Implementierung von Swimlanes in Ereignisgesteuerten Prozessketten 63

64 A. Fragebogen Fragebogen 2/4 1.1 Bewerten sie bitte die 4 Varianten: (Schulnoten von 1 bis 6) Übersichtlichkeit: Variante 1: Variante 2: Variante 3: Variante 4: Brauchbarkeit (im Betrachten): Variante 1: Variante 2: Variante 3: Variante 4: Handhabbarkeit (im Erstellen): Variante 1: Variante 2: Variante 3: Variante 4: 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 Konzept und Implementierung von Swimlanes in Ereignisgesteuerten Prozessketten 64

65 A. Fragebogen Fragebogen 3/4 Eine weitere Möglichkeit ist in Abbildung 9 und 10 dargestellt. Hierbei bleiben die Hierarchien getrennt 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, das das Ausführen der eigenen Funktion bestätigt. Dieses wird mit dem gleichwertigen Ereignis der anderen Swimlane AND-verknüpft. Da am Ende eines Prozesses eine Ereignis eintreffen muss, wird zusätzlich eine Funktion eingeführt. Innerhalb dieser Funktion wird nichts gemacht. Sie dient lediglich zur Einhaltung der Syntax. Variante 2: Anstatt Ereignisse einzuführen, wird hier die Funktion der Nachbarswimlane eingeführt. Allerdings hätte man in diesem Fall Organisationseinheiten innerhalb einer Swimlane, was eigentlich dem Prinzip der Swimlanes widerspricht. Abbildung 11: AND-Verknüpfung Abbildung 12: Variante 1 Abbildung 13: Variante Welche Variante würden sie präferieren? Variante 1 Variante Wie könnte man eine solche AND-Verknüpfung noch realisieren? Konzept und Implementierung von Swimlanes in Ereignisgesteuerten Prozessketten 65

66 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 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) Abbildung 15: Swimlane Informationsobjekte Vielen Dank für ihre Unterstützung Konzept und Implementierung von Swimlanes in Ereignisgesteuerten Prozessketten 66