Diplomarbeit Konzeption und prototypische Implementation einer

Diplomarbeit
Konzeption und prototypische
Implementation einer Rich Internet
Application zur Modellierung von
Human(Workflow)-Geschäftsprozessen
vorgelegt von
Manfred Schuljak
Busdorfwall 14
33098 Paderborn
Matrikelnummer: 6014690
Prüfer:
Prof. Dr. Ludwig Nastansky
Prof. Dr. Gerd Szwillus
Betreuer:
Dr. Rolf Kremer
Fachgebiet Informatik
Fakultät für Elektrotechnik, Informatik und Mathematik
Universität Paderborn
Paderborn, 22. März 2010
Ich erkläre hiermit, dass ich die vorliegende Diplomarbeit selbstständig ohne Hilfe Dritter und ohne Benutzung anderer als der angegebenen Quellen
und Hilfsmittel verfasst habe. Alle den benutzten Quellen wörtlich oder
sinngemäß entnommenen Stellen sind als solche einzeln kenntlich gemacht.
Diese Arbeit ist bislang keiner anderen Prüfungsbehörde vorgelegt worden
und auch nicht veröffentlicht worden.
Paderborn, den 22. März 2010,
Inhaltsverzeichnis
1 Einleitung
2
1.1
Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.2
Aufgabenstellung und Zielgruppe . . . . . . . . . . . . . . . . . . . . . . .
3
1.3
Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2 Analyse
bestehender
visueller
Sprachen
zur
Modellierung
von
Geschäftsprozessen
5
2.1
Petrinetze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.1.1
Klassische Petri - Netze . . . . . . . . . . . . . . . . . . . . . . . .
6
2.1.2
High Level Petri-Netze . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.1.3
Petri-Netze Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2
UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3
BPMN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4
Vergleich von BPMN und UML . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4.1
BPMN und UML-Aktivitätendiagramm . . . . . . . . . . . . . . . . 22
2.4.2
Anwendung der Notationen zur Geschäftsprozessmodellierung . . . 30
3 Abgrenzung bestehender Ausführungssprachen
3.1
32
BPEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.1.1
Dokumentaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.1.2
Umgebungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.1.3
BPEL4People . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.1.4
Beziehungen zu anderen Spezifikationen
. . . . . . . . . . . . . . . 36
INHALTSVERZEICHNIS
3.2
3.3
XPDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2.1
Conformance Klasse . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.2
Metamodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.2.3
Teilnehmer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.2.4
Pools & Lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2.5
Aktivitäten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2.6
Applikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4 Rich Internet Application Technologien
4.1
4.2
ii
42
Vergleich bestehender Rich Internet Application Technologien . . . . . . . 43
4.1.1
AJAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.1.2
Adobe Flex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5 Kontept/Architektur des Business Process Modeler
50
5.1
Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.2
Design und Entwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.3
5.2.1
Grobentwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.2.2
Feinentwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6 Zusammenfassung und Ausblick
73
A Hinweise zur beigelegten CD
75
B Tabelle der Werkzeuge zur Geschäftsprozessmodellierung
76
Literaturverzeichnis
79
Abbildungsverzeichnis
2.1
Beispiel einer Transitionsschaltung in Petri-Netzen vgl. [Fro10] . . . . . . .
7
2.2
Beispiel eines simplen Arbeitsablaufs modelliert mit Petri-Netzen vgl. [Lau10]
8
2.3
Beispiele für WF-Netze-Operatoren vgl. [vdA] . . . . . . . . . . . . . . . . 10
2.4
Beispiel eines WF-Netzes mit Triggern vgl. [vdA] . . . . . . . . . . . . . . 10
2.5
Typen der Ereignisse. a) Startereignis b) Zwischenereignis c) Endereignis . 15
2.6
Aktivität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.7
Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.8
Sequenzfluss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.9
Nachrichtenfluss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.10 Assoziation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.11 Swimlanes. a) Pool b) Lane vgl. [pre10] . . . . . . . . . . . . . . . . . . . . 18
2.12 Beispiel eines Diagramms mit Pool vgl. [pre10] . . . . . . . . . . . . . . . . 18
2.13 Ein Prozess mit Lanes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.14 Artefakte. a) Datenobjekt b) Gruppe c) Annotation . . . . . . . . . . . . . 19
2.15 Ein Prozess mit Datenobjekt, Gruppe und Annotation . . . . . . . . . . . 20
2.16 Sequenz - Geschäftsprozessdiagramm. vgl. [Whi06] . . . . . . . . . . . . . . 22
2.17 Sequenz - Aktivitätendiagramm. vgl. [Whi06] . . . . . . . . . . . . . . . . 23
2.18 Parallele Spaltung - Geschäftsprozessdiagramm. Mechanismus 1. vgl. [Whi06] 23
2.19 Parallele Spaltung - Geschäftsprozessdiagramm. Mechanismus 2. vgl. [Whi06] 24
2.20 Parallele Spaltung - Geschäftsprozessdiagramm. Mechanismus 3. vgl. [Whi06] 24
2.21 Parallele Spaltung - Aktivitätendiagramm. vgl. [Whi06] . . . . . . . . . . . 25
ABBILDUNGSVERZEICHNIS
iv
2.22 Synchronisation - Geschäftsprozessdiagramm. Mechanismus 1. vgl. [Whi06]
26
2.23 Synchronisation - Geschäftsprozessdiagramm. Mechanismus 2. vgl. [Whi06]
26
2.24 Synchronisation - Aktivitätendiagramm. vgl. [Whi06] . . . . . . . . . . . . 27
2.25 Ausschließende Wahl - Geschäftsprozessdiagramm. vgl. [Whi06] . . . . . . 28
2.26 Ausschließende Wahl - Aktivitätendiagramm. vgl. [Whi06] . . . . . . . . . 28
2.27 Einfaches Mischen - Geschäftsprozessdiagramm. Variante 1. vgl. [Whi06] . 29
2.28 Einfaches Mischen - Geschäftsprozessdiagramm. Variante 2. vgl. [Whi06] . 29
2.29 Einfaches Mischen - Aktivitätendiagramm. vgl. [Whi06] . . . . . . . . . . . 30
3.1
Modellierung eines Geschäftsablaufs am Beispiel einer Bäckerei . . . . . . . 37
4.1
RIA-Architektur vgl. [Wal08] . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2
Einsatzbereich für RIA-Technologie vgl. [Wal08] . . . . . . . . . . . . . . . 44
5.1
Systemarchitektur: Externe Anforderungen . . . . . . . . . . . . . . . . . . 53
5.2
Überblick der Softwarearchitektur . . . . . . . . . . . . . . . . . . . . . . . 54
5.3
Benutzeroberfläche. Standardkomponenten. . . . . . . . . . . . . . . . . . . 57
5.4
Schnellzugangsleiste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.5
Akkordeon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.6
Uiaccordeon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.7
Lasso im Einsatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.8
Lasso-Klasse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.9
Aktivitäten-Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.10 BPMNElement Klasse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.11 Elemente der Klassenstufe 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.12 Elemente der Klassenstufe 3 . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.13 Klassenhierarchie der BPMN-Elemente. . . . . . . . . . . . . . . . . . . . . 64
5.14 Abbildung der PAVONE-Prozessdefinitionsdatei auf einen Baum . . . . . . 66
5.15 Teilbaum für allgemeine Einstellungen . . . . . . . . . . . . . . . . . . . . 66
5.16 Aktivitäten-Teilbaum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
ABBILDUNGSVERZEICHNIS
1
5.17 Zustandsautomat bei Aktivierung und Verwendung des Lasso Elements . . 69
5.18 Geladener Geschäftsablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.19 allgemeine Einstellungen Dialog . . . . . . . . . . . . . . . . . . . . . . . . 70
5.20 Direkte Tastatureingabe auf einem Aktivitaten Element . . . . . . . . . . . 71
5.21 PAVONE ProcessModeler . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.22 Mögliches Einbindungsszenario des Modelers innerhalb der PAVONE Live
Umgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Kapitel 1
Einleitung
1.1
Motivation
Die Verwaltung von Arbeitsabläufen in einem Unternehmen oder einer Organisation ist
eine wichtige und komplexe Aufgabe, um erfolgreiche Betriebswirtschaft zu führen. Die
Anforderungen umfassen dabei sowohl unternehmensinterne als auch unternehmensübergreifende Prozesse. Ressourcen, Aktivitäten der Mitarbeiter, Zusammenarbeit mit Partnern und Kunden sind Gegenstand des Geschäftsmanagements und erfordern effektive
Methoden zur Gestaltung und Modellierung der unternehmerischen Tätigkeit.
Eine Hilfe dafür bieten Geschäftsprozessmodellierungswerkzeuge, die die Erzeugung und
Verwaltung der Prozessmodelle unter Beachtung der Spezialisierung der Organisation
ermöglichen. Der Markt von diesen Modellierungswerkzeugen hat sich in den letzten Jahren zunehmend weiterentwickelt und der Einsatz von diesen Werkzeugen erweist sich
dementsprechend für viele Unternehmen als eine Voraussetzung für eine sichere Planung
und Ausführung der Geschäftsprozesse.
Je nach der Zielstellung werden verschiedene Modellierungsansätze und Modellelemente
benötigt, was eine Varietät an Notationen - auch Modellierungssprachen - und Muster
der von den Herstellern entwickelten und vermarkteten Modellierungsansätze mit sich
bringt. Es steht somit eine Vielzahl von Modellierungswerkzeugen zur Verfügung, die
allerdings keinen einheitlichen Standard verwenden und darüber hinaus Erweiterungen
in den Notationen zulassen, um kundenindividuellen Anforderungen nachzukommen, was
die Anwendung dieser Produkte für verschiedene Benutzergruppen verkompliziert.
Es entsteht damit ein Bedarf an einer konsistenten und standardisierten Lösung des
Geschäftsprozessmanagements, welche in Form von Software für alle Benutzergruppen
einheitliche und intuitiv bedienbare Modellierungswerkzeuge zur Verfügung stellt. Zurzeit
1 Einleitung
3
hat sich neben den vielfältigen Formen der Notationen und Modellierungssprachen ein
neuer Standard durchgesetzt und wird bereits von vielen Anbietern unterstützt. Dieser
Standard wurde von der BPMI (Business Process Management Initiative) entwickelt und
wird als BPMN (Business Process Management Notation) bezeichnet. Das Ziel von BPMN
ist es, eine Notation zu liefern, die für alle an Prozessdesign und -implementierung beteiligten Personengruppen verständlich ist. In diesem Zusammenhang bietet ein auf BPMN
basiertes Tool eine benutzerfreundliche Modellierungsumgebung und gewährleistet zudem,
dass die Sprachen, die für die Ausführung der Geschäftsprozesse entwickelt wurden, solche wie BPEL (Business Process Execution Language), mit einer gemeinsamen Notation
visualisiert werden könnten.
Ein Vorteil für die Unternehmen, die Applikationen für den Betrieb ihres Geschäfts benötigen, kann im Einsatz des SaaS (Software as a Service)-Prinzips bestehen, bei welchem die
Instandhaltung von Applikationen vom Dienstanbieter übernommen wird. Bei diesem Modell mieten die Endnutzer die Software, in der Regel auf monatlicher Basis, und müssen
sie nicht kaufen. Damit erhalten die Kunden eine flexible und praktische Lösung, so dass
sie sich auf den Betrieb ihres Unternehmens konzentrieren können und sich nicht mit
dem Kauf und der Patch- und Update-Verwaltung von Software-Applikationen auseinandersetzen müssen. Dieser Trend ist eines der am schnellsten wachsenden Segmente der
IT-Industrie [DKKZ08].
Für die Darstellung und den Einsatz der SaaS-Produkte gibt es unterschiedliche Ansätze.
Neben dem statischen Export finden sich integrierte Webanwendungen, die jederzeit den
aktuellen Zustand der Modelle anzeigen und auch die Erzeugung und Verwaltung der
Prozessmodelle direkt im Browser möglich machen.
1.2
Aufgabenstellung und Zielgruppe
Das Ziel dieser Arbeit ist, gängige visuelle und Ausführungssprachen zur Modellierung
von Geschäftsprozessen zu analysieren und zu untersuchen, wie diese Konzepte für eine
Rich Internet Application (RIA) zur Modellierung von Human (Workflow)-Geschäftsprozessen angewendet werden können. Da die Modellierung mithilfe von visuellen Sprachen
erfolgt, die Ergebnisse der Modellierung aber maschinell ausführbar sein müssen, sind
dafür entsprechende Ausführungssprachen erforderlich. Es müssen deswegen verschiedene
am Markt existierende Ausführungsengines ermittelt und verglichen werden. Ein weiterer
Aspekt der Arbeit liegt in der Konzeption und prototypischen Umsetzung eines Werkzeugs zur Modellierung von Geschäftsprozessen, welches im Rahmen einer SaaS-Lösung
implementiert werden soll. Zu diesem Zweck werden vorhandene Technologien und Ent-
1 Einleitung
4
wicklungsframeworks zum Erstellen von Rich Internet Applications untersucht. Die Applikation soll vollständig im Webbrowser nutzbar sein, ohne eine Installation auf der lokalen
Festplatte durchführen zu müssen.
Zu der Zielgruppe gehören die Mitarbeiter der Geschäftsleitungsabteilungen, die die
Geschäftsprozesse entwerfen, verwalten und kontrollieren. Es wird dabei nicht vorausgezetzt, dass sie über fundierte Kenntnisse in der Implementierung der Technologie zur
Ausführung der Prozesse und über technisches Hintergrundwissen im informationstechnischen Bereich verfügen. Im Folgenden wird diese Gruppe als Fachanwender bezeichnet.
1.3
Aufbau der Arbeit
Zunächst wird im Kapitel 2 ein Überblick über die bestehenden visuellen Sprachen zur
Modellierung von Geschäftsprozessen gegeben. Es werden gängige Notationen untersucht
und miteinander verglichen. Das Ziel dieser Untersuchung ist es, einen Zusammenhang
zwischen der Aufgabenstellung und den dafür geeigneten Modellierungstechniken herzustellen. Im darauffolgenden Kapitel werden die Ausführungssprachen behandelt. Darin
werden die bestehenden Ausführungssprachen vorgestellt und deren detaillierte Analyse
beleuchtet. Kapitel 4 widmet sich den Rich Internet Application Technologien. Es wird
die Möglichkeit für den Einsatz der Geschäftsprozessmodellierung in Webanwendungen
aufgezeigt und die Entscheidung über die Wahl der in der vorliegenden Arbeit verwendeten RIA-Technologie begründet. Im Kapitel 5 werden das Konzept und die Architektur des in der Arbeit umgesetzten Business Process Modelers beschrieben und erklärt.
Das abschließende Kapitel fasst die Ergebnisse dieser Arbeit zusammen. Offen gebliebene Fragestellungen sowie Anregungen für weiterführende Arbeiten werden als Ausblick
behandelt.
Kapitel 2
Analyse bestehender visueller
Sprachen zur Modellierung von
Geschäftsprozessen
Geschäftsprozessmodellierung bedeutet, einen bestehenden Geschäftsprozess zu beschreiben und zu verstehen und mit den Ergebnissen der Geschäftsprozessmodellierung die
Geschäftsprozesse zu analysieren, zu verbessern und die Verbesserung umzusetzen.
Geschäftsprozessmodellierung ist keine neue Technik, es gibt bereits eine Vielzahl von Methoden und Techniken, um Prozesse zu beschreiben. Jede Modellierungssprache, welche
durch äußere Ereignisse gesteuerte Abläufe modellieren kann, eignet sich grundsätzlich zur
Modellierung von Arbeits- bzw. Geschäftsprozessen. Gebräuchlich sind UML-Aktivitätsdiagramme, möglich sind ferner Petrinetze und Flußdiagramme. Eine Übersicht der Standardnotationen zur Geschäftsprozessmodellierung bietet die Tabelle, die vom Fraunhofer
IAO in der Marktstudie zur Geschäftsprozessmanagementwerkzeugen entsprechend der
Angaben der Hersteller erstellt wurde und die im deutschsprachigen Raum angebotenen
Werkzeuge, die diese Notationen unterstützen, zeigt [DKKZ08]. Die Tabelle kann dem Anhang B dieser Arbeit entnommen werden. Die zahlreichen Modellierungssprachen sollen
die Geschäftsprozesse aus unterschiedlichen Blickwinkeln beleuchten und auf diese Weise
überschaubar bleiben, zusammengenommen aber ein Gesamtbild des Geschäftsprozesses
abgeben. Modelle richten sich nach Anforderungen und basieren auf Elementen der Modellierungssprachen. Der Sprachumfang dieser Sprachen ist dabei unabhängig von Programmiersprachen und Plattformen. Die errichteten Modelle sind somit ebenfalls unabhängig
von derartigen Technologien. Egal, welche Programmiersprachen und Plattformen in Zukunft wichtig sein werden - die Modelle bleiben gültig und müssen nicht an technische
Entwicklungen angepasst werden.
2 Analyse bestehender visueller Sprachen zur Modellierung von Geschäftsprozessen
6
Im Folgenden wird eine Abgrenzung bestehender Modellierungssprachen vorgestellt. Die
Auswahl der betrachteten Sprachen orientiert sich an der Entstehungszeit und der Bedeutung für das Prozessmanagement. So wurden Petrinetze als eine der ältesten formalen
Modellierungsmethoden, die UML als einer der in der Praxis am häufigsten eingesetzten
Modellierungsansätze und BPMN als der sich in den letzten Jahren durchgesetzte Standard zur Analyse genommen. Es werden die Charakteristika der Sprachen gegeben und
ihre Tauglichkeit zur Modellierung der Geschäftsprozesse diskutiert. Zum Schluß werden
BPMN und die Aktivitätsdiagramme von UML miteinander verglichen und die Unterschiede in der Verwendung der beiden Notationen aufgezeigt.
2.1
Petrinetze
Petri-Netze wurden durch Carl Adam Petri in den 1960er Jahren definiert [Bal93]. Hierbei
handelt es sich um eine mathematische formal definierte Methode, die ursprunglich fur die
Beschreibung, Analyse und Simulation von dynamischen Systemen eingesetzt wurde. Die
Petri-Netze erlauben es, dynamische und parallele Prozesse zu beschreiben, sowie Nebenlaufigkeiten oder das Zusammenwirken von Prozessen abzubilden [DKKZ08]. Nach wie
vor ist das Simulieren das zentrale Anwendungsfeld der Petri-Netze. Fur die Modellierung
von Geschaftsablaufen wurden die Petri-Netze erst später entdeckt.
2.1.1
Klassische Petri - Netze
Ein Petri-netz ist ein 6-Tupel (S,T,F,K,W,m0 )
• S, nichtleere Menge von Stellen S = {s1 , s2 , ..., sn }
• T, nichtleere Menge von Transitionen T = {t1 , t2 , ..., tn }
• F, nichtleere Menge der gerichteten Kanten F ⊆ (S x T) ∪ (T x S)
• K, Kapazitäten der Plätze, K : S → N ∪ {∞}
• - Kosten der Kanten, Gewichtsfunktion W: F → N
• m0 , Startmarkierung m0 : S → N
N - die Anzahl der Knoten
Eine Stelle S wird als ein Kreis, eine Transiton T als ein Rechteck dargestellt. Diese Elemente können miteinander mittels gerichteter Kanten verbunden werden. Untereinander
2 Analyse bestehender visueller Sprachen zur Modellierung von Geschäftsprozessen
7
können jeweils nur eine Stelle mit einer Transition oder umgekehrt eine Transition mit
einer Stelle verbunden werden. Verbinden von gleichartigen Elementen ist nicht möglich.
Kanten, die von den Stellen zu einer Transition laufen, heißen Eingabestellen von T. Die
Stellen, zu denen von t aus Kanten führen, heißen Ausgabestellen von T. Die Kanten
können mit einem Gewicht belegt werden. Einer Stelle kann eine Kapazität zugewiesen
werden, welche einer maximal möglichen Anzahl der Markierungen, die sich zu einem Zeitpunkt innerhalb einer Stelle befinden können, entspricht. Die Startmarkierung m0 gibt
die Verteilung der Markierungen auf die Stellen im Anfangszustand an. Die Markierung
selbst wird als ein Punkt dargestellt. Eine Verteilung von Marken auf das Petri-Netz stellt
den aktuellen Zustand eines Petri-Netzes dar.
Ein sehr simpler Schaltungsschritt ist in der Abbildung 2.1 zu sehen. Die Transition T1
kann erst dann schalten, wenn mindestens zwei Markierungen an der Stelle S1 vorhanden
sind, weil die Schaltungsvoraussetzung durch die Kapazität der Verbindung w = 2 gegeben
ist. Nach dem Schaltungsschritt werden zwei Markierungen aus der Stelle S1 entfernt und
drei Markierungen (da Gewicht der Verbindung von T1 nach S2 w = 3 ist) der Stelle
S2 hinzugefügt. Danach ist kein Schaltvorgang in dem Petrinetz mehr möglich, da zum
einen die Schaltungsvoraussetzung (w=2) nicht erfüllt ist und zum anderen die Kapazität
der Stelle S2 (da K Maximum 3) erschöpft ist. Zur Analyse eines Petrinetzes wird ein so
w=3
w=2
T1
S1
w=3
w=2
S2
S2
T1
S2
Bild 2.1: Beispiel einer Transitionsschaltung in Petri-Netzen vgl. [Fro10]
genannter Erreichbarkeitsgraph erstellt und auf bestimmte Eigenschaften (Lebendigkeit,
Reversibilität etc.) untersucht.
Je nach Verwendungszweck werden den Stellen und Transitionen unterschiedliche Rollen
zugewiesen. Im Falle einer Workflow Anwendung entspricht einer Transition eine Aktivität und einer Stelle Anfangs- und Endbedingungen für die Ausführung einer Aktivität.
Markierungen repräsentieren Objekte des zu modellierenden Systems (Ressourcen, Personen, etc). Ein Beispiel einer simplen Workflow-Anwendung ist in der Abbildung 2.2 zu
sehen. Falls das Dokument vorhanden und ein Mitarbeiter bereit ist, kann die Dokumentbearbeitungsaktivität T1 erfolgen.
2 Analyse bestehender visueller Sprachen zur Modellierung von Geschäftsprozessen
8
Dokument
Vorhanden
Dokument wird vom
Mitarbeiter bearbeitet
Beginne
Bearbeitung
Beende
Bearbeitung
Mitarbeiter
bereit
Bild 2.2: Beispiel eines simplen Arbeitsablaufs modelliert mit Petri-Netzen vgl. [Lau10]
2.1.2
High Level Petri-Netze
Ein Versuch, reale Prozesse mittels der Petri-Netze zu modellieren, führt gewöhnlich auf
eine viel zu komplexe Darstellung des zu modellierenden Vorgangs. Des Weiteren wird
in der klassischen Petri-Netz-Notation die Modellierung von Datum und Zeit nicht unterstützt. Um diese Probleme zu lösen, wurden mehrere Erweiterungen des klassischen
Petri-Netze Modells eingeführt. Die drei Häufigsten sind: Farb-, Zeit- sowie Hierarchieerweiterungen. Ein Petri-Netz mit mindestens einer dieser Erweiterungen wird als High
Level Petri-Netz bezeichnet [vdA]. Im Folgenden werden diese Erweiterungen kurz informell beschrieben.
Farberweiterung
Wie bereits erwähnt, werden die Markierungen zur Modellierung von Ressourcen, Personen sowie weiteren Objekten verwendet. Dies führt zwangsläufig zur Notwendigkeit, die
Attribute dieser Objekte, wie zum Beispiel den Namen einer Person oder Inventarnummer einer Ressource, visuell darzustellen. Hierfür wird das klassische Modell um farbige
Markierungen erweitert [JK09]. Zu diesem Zweck wird ein Attribut einer bestimmten
Farbe zugewiesen. Bei der Schaltung einer Transition wird die Farbe der zu erzeugenden
Markierung anhand der Farben von konsumierten Markierungen berechnet.
Zeiterweiterung
Bei der Modellierung real vorhandener Systeme ist es notwendig, die Dauer sowie Verzögerungen zwischen den Abläufen zeitlich zu steuern. Das klassische Petri-Netz Modell kann
zu diesem Zweck auf unterschiedliche Art und Weise, wie zum Beispiel mittels der Asso-
2 Analyse bestehender visueller Sprachen zur Modellierung von Geschäftsprozessen
9
ziation der Zeit mit Markierungen, Stellen und Transitionen, erweitert werden.
Hierarchieerweiterung
Die Erweiterung mit Zeit und Farbe erlaubt es bereits, Geschäftsabläufe auf eine effiziente
Weise zu modellieren. Jedoch neigt die Modellierung eines real vorhanden Systems zu
Unübersichtlichkeit und zu einer viel zu komplexen Darstellungsform. Um dieses Problem
zu lösen, wird ein so genanntes Subnetz-Konstrukt [vdA] eingeführt. Dieses Konstrukt
wird benutzt, um komplexe Prozesse zu strukturieren. Einerseits ist es möglich, einen
Prozess vereinfacht und übersichtlich darzustellen, ohne jedes einzelne Detail des Prozesses
zu betrachten, andererseits kann innerhalb des Subnetzes detailliert spezifiziert werden.
WorkFlow-Netz
Eine weitere Erweiterung für Petri-Netze ist das so genannte WorkFlow-Netz (kurz WFNetz). Diese Notation wurde an der Universität Eindhoven von Prof. Aals [vdA] mit dem
Ziel entwickelt, eine einfache Modellierung von Arbeitsabläufen zu ermöglichen. WF-Netz
genügt folgenden Bedingungen: WF-Netz verfügt über eine Eingabestelle (i) und eine
Ausgabestelle (o). Jede Aktivitätsdefinition muss auf dem Pfad zwischen i und o erreichbar
sein. Jede Aktivitätsdefinition muss mindestens einmal beim Durchlauf vom Startzustand
bis zum Endzustand ausgeführt werden.
WF-Netz Formale Definition: Ein Petri - Netz PN = (S,T,F,K,W,m0 ) ist ein WFNetz (WorkFlow Netz) wenn:
(i) PN besitzt zwei spezielle Stellen: i und 0. Die Stelle i ist die Quellstelle *i = 0. Die
Stelle 0 ist eine Zielstelle 0* =0;
(ii) Falls eine Transtion t* zu PN* hinzugefügt wird, welche die Stelle 0 mit der Stelle i
verbindet (i.e *t* = {0} und t* = {i}), dann ist das resultierende Petri-Netz strongly
connected.
WorkFlow Netz Operatoren: Um eine bessere Lesbarkeit zu gewährleisten, wird in
der WF-Netz Notation die Verwendung von booleschen Operatoren (AND, OR, XOR,
usw) unterstützt. Links in der Abbildung 2.3 ist die klassische Variante und rechts ein
Analogon in der WF-Netz Variante zu sehen.
2 Analyse bestehender visueller Sprachen zur Modellierung von Geschäftsprozessen
10
T1
OR-Split
T1
T2
T3
T1
XOR-Join
T1
T2
WF-Netz: Operatoren
Klassisches Petri-Netz
Bild 2.3: Beispiele für WF-Netze-Operatoren vgl. [vdA]
Trigger In WF-Netzen ist es möglich, den einzelnen Transitionen einen oder mehrere
Auslöser (Trigger) hinzuzufügen. Insgesamt existieren drei Triggerarten: externes Ereignis, Ressource als Auslöser und Zeitereignis. Eine Transition wird aktiviert, wenn eines
dieser Ereignisse eintritt. Dieses Konzept erlaubt die Arbeitsabläufe zu automatisieren.
Ein Beispiel eines solchen Ablaufs ist in der Abbildung 2.4 zu sehen.
T1
T2
T3
Bild 2.4: Beispiel eines WF-Netzes mit Triggern vgl. [vdA]
2.1.3
Petri-Netze Fazit
Petri-Netze sind ein mathematisch definiertes Konstrukt, dessen Stärke in der Parallelisierung und Simulation von Abläufen liegt. Es handelt sich jedoch um eine Notation,
die ursprünglich nicht zur Modellierung von Arbeitsabläufen entwickelt wurde. Zusätzliche Erweiterungen ermöglichen zwar insgesamt ein benutzerfreundliches Arbeiten, führen
aber in der Praxis auf viel zu komplexe und schwer leserliche Strukturen. Des Weiteren ist
2 Analyse bestehender visueller Sprachen zur Modellierung von Geschäftsprozessen
11
die Petri-Netz Notation zu technisch und kann nur durch die Benutzer mit technischem
Hintergrund verstanden und verwendet werden.
2.2
UML
Die UML ist in ihrem Ursprung eine Notation zur Spezifikation, Konstruktion, Visualisierung und Dokumentation von Modellen für Softwaresysteme. [OWS+ 03] Die Geschäftsprozessmodellierung hat zunächst zu der Softwareentwicklung keine direkte Beziehung, dadurch aber, dass die Abläufe in einem Unternehmen zum großen Teil durch Software
unterstützt werden, entsteht ein Bezug der Geschäftsprozessmodellierung zur Softwareentwicklung. Damit ist die UML, obwohl sie in erster Linie zur Beschreibung objektorientierter Softwaremodelle dient, auch für die Modellierung von Geschäftsprozessen geeignet.
Den Vorteil, Geschäftsprozessmodellierung mit der UML auszuüben, bieten einheitliche
Beschreibungssprache, die Benutzung gleicher Werkzeuge und eine einheitliche Struktur
zur Ablage, Verwaltung und Dokumentation. Außerdem können die Anforderungen an
die Software besser nachvollzogen und im Kontext der Betriebswirtschaft wahrgenommen
werden.
Mit den UML-Aktivitätsdiagrammen werden Abläufe grafisch dargestellt und im Vergleich
zu der natürlichen Sprache, mit welcher gewöhnlich nur einfache Abläufe verständlich
beschrieben werden können, ermöglichen es die Aktivitätsdiagrammen, auch komplexe
Abläufe mit vielen Ausnahmen, Sprüngen und Wiederholungen noch übersichtlich und
verständlich darzustellen.
Als Modellierungssprache stellt die UML geometrische Formen zur Verfügung, mit denen
Softwaremodelle erstellt werden können. Die zusammengesetzten geometrischen Formen
ergeben Zeichnungen, die bestimmte Strukturen einer Software oder Abläufe in einer Software repräsentieren. In den Diagrammen werden unterschiedliche Aspekte der Software
hervorgehoben. Jedes Diagramm stellt demzufolge ein Modell dar, welches bestimmte
Aspekte der Software hervorhebt. Die Software wird durch Diagramme aus verschiedenen
Gesichtspunkten beschrieben.
Je nach dem Gesichtspunkt sind unterschiedliche geometrische Formen und Regeln zum
Zusammenstellen dieser Formen notwendig und die UML definiert 13 Diagrammtypen.
Die UML weist diese Diagrammtypen entweder den Strukturdiagrammen oder den Verhaltensdiagrammen zu. Die Strukturdiagramme sind Modelle einer Struktur und sind somit
statisch. Sie stellen Zusammenhänge in einer Software zu einem bestimmten Zeitpunkt
dar. Verhaltensdiagramme hingegen erklären Abläufe. Sie sind dynamisch und stellen Zusammenhänge im Zeitablauf dar.
2 Analyse bestehender visueller Sprachen zur Modellierung von Geschäftsprozessen
12
Folgende sechs Diagrammtypen werden zu den Strukturdiagrammen gezählt.
• Klassendiagramm: Das Klassendiagramm ist der wichtigste Diagrammtyp in der
UML. Damit werden Klassen beschrieben und Zusammenhänge zwischen Klassen
repräsentiert.
• Objektdiagramm: Mit diesem Diagrammtyp werden die während der Laufzeit zu einem bestimmten Zeitpunkt existierenden Objekte und deren Zusammenhänge dargestellt. Während Klassen im Laufe des Programms existieren, können Objekte
erstellt und zerstört werden. Das Objektdiagramm ist daher eine momentane Aufnahme, während das Klassendiagramm zeitlos ist.
• Komponentendiagramm: Diese Diagramme gehen auf das Konzept von Komponenten zurück, mit welchem Einheiten beschrieben werden, die die nächsthöhere Ebene
über den Klassen darstellen und in erster Linie über Schnittstellen beschrieben werden.
• Kompositionsstrukturdiagramm: Das Kompositionsstrukturdiagramm kann als Gegenstück zum Komponentendiagramm aufgefasst werden - es beschreibt die interne
Struktur von Kompositionen.
• Verteilungsdiagramm: Dieser Diagrammtyp ist insbesondere für verteilte Software
tauglich, wenn gezeigt werden muss, auf welchen Geräten welche Programme ausgeführt werden und wie diese Programme miteinander kommunizieren.
• Paketdiagramm: In diesem Diagramm werden Klassen zu Paketen gruppiert. Pakete
werden eingesetzt, um Klassen übersichtlich anzuordnen.
Zu den Verhaltensdiagrammen zählen folgende sieben Diagrammtypen.
• Use-Case-Diagramm: Dieser Diagrammtyp beschreibt, wie die zu modellierende
Software mit dem Anwender interagiert. Use-Case-Diagramme werden eingesetzt,
um Anforderungen an eine zu entwickelnde Software zu beschreiben.
• Aktivitätsdiagramm: Das Aktivitätsdiagramm ist das universale Diagramm in der
UML zur Beschreibung von Abläufen. Es beschreibt den Ablauf von Aktionen und
ist in seinen Darstellungsmöglichkeiten sehr flexibel.
• Zustandsautomat: Der Zustandsautomat beschreibt einen Ablauf nicht als Aneinanderreihung von Aktionen, sondern als Zustandswechsel.
• Sequenzdiagramm: Das Sequenzdiagramm beschreibt die Abläufe, die zwischen mehreren interagierenden Partnern stattfinden. Das können Klassen oder Objekte sein.
2 Analyse bestehender visueller Sprachen zur Modellierung von Geschäftsprozessen
13
• Kommunikationsdiagramm: Das Kommunikationsdiagramm ist eine Form des Sequenzdiagramms, wobei der Fokus nicht auf den Abläufen zwischen interagierenden
Partnern liegt, sondern auf den interagierenden Partnern selbst.
• Timing-Diagramm: Timing-Diagramme werden in den Fällen eingesetzt, wenn nicht
nur die Reihenfolge von Abläufen von Bedeutung ist, sondern auch Zeitangaben
wichtig sind. So wird im Timing-Diagramm beschrieben, nach wie vielen Sekunden
eine Aktion auf eine andere folgen muss.
• Interaktionsübersichtsdiagramm: Dieser Diagrammtyp vereint mehrere Verhaltensdiagramme, um deren Zusammenwirkung zu repräsentieren. Es können mehrere Aktivitäts- und Sequenzdiagramme in einem Interaktionsübersichtsdiagramm zusammengefügt werden, um Zusammenhänge zwischen den in verschiedenen Diagrammen
abgebildeten Abläufen darzustellen.
Unter diesen Diagrammtypen werden Diagramme für dynamisches Verhalten, solche wie UML-Aktivitätsdiagramme und Use-Case-Diagramme, häufig verwendet, um
Geschäftsprozesse zu modellieren.
Obwohl die UML eine flexible Notation ist, hat der Bereich Geschäftsprozessmodellierung
in der UML keinen besonderen Platz und wird nicht hinreichend unterstützt. Es sind auch
nicht alle Elemente enthalten, die für die Modellierung von Geschäftsprozessen notwendig
sind. Die in der UML enthaltenen Use-Cases bieten einen Ansatzpunkt, werden aber
meistens mit natürlicher Sprache beschrieben. Nach festgelegten formalen Regeln können
jedoch Erweiterungen vorgenommen werden. Dabei wird ein so genanntes UML-Profil
[BE] für Geschäftsprozessmodellierung genutzt.
Im Gegensatz zu der im Aktivitätsdiagramm vorgesehenen Komponente Aktivität hat ein
Prozess zusätzliche zu modellierende Merkmale [BE]. So hat ein Prozess ein oder mehrere
Ziele. Er verwendet spezifische Input-Objekte und analog dazu spezifische Output-Objekte
unterschiedlichen Typs. Er benötigt Ressourcen zur Durchführung von Aktivitäten und
besteht aus einer Anzahl Aktivitäten, die in Abhängigkeit von Ereignissen oder Bedingungen (Business Rules) in einer bestimmten Reihenfolge ausgeführt werden müssen. Er
betrifft mehr als eine Organisationseinheit und erzeugt einen erkennbaren Mehrwert für
den Kunden. Die Geschäftsprozessmodellierung bedingt damit die Einführung einer Reihe
zusätzlicher Konzepte wie z. B. Ziele, Ressourcen, Organisationseinheiten, die in UML in
dieser Form nicht vorhanden sind.
Sofern nur einfache Diagrammelemente wie Aktivitäten und Transitionen verwendet werden, sind solche Diagramme weitgehend allgemein verständlich. Bei Verwendung spezieller Konstrukte wie beispielsweise Signale, Objektknoten etc. sind hingegen grundlegende
2 Analyse bestehender visueller Sprachen zur Modellierung von Geschäftsprozessen
14
UML-Kenntnisse notwendig. Somit ist die Verwendung von UML mehr in den Projekten
geeignet, wo technische Kräfte mit entsprechenden Kenntnissen eingesetzt sind.
2.3
BPMN
BPMN ist eine Abkürzung für Business Process Modeling Notation. Es ist ein neuer
Standard für die Modellierung von Geschäfts- und Web-Service-Prozessen, entwickelt von
BPMI - Business Process Management Initiative [Whi04a]. Das primäre Ziel von BPMN
ist es, eine Notation zu liefern, die für alle Fachanwender verständlich ist, beginnend mit
den Geschäftsanalytikern, die die ersten Skizzen der Prozesse entwerfen, bis zu den technischen Entwicklern, die die Technologie implementieren, welche diese Prozesse ausführen
wird, und, letztendlich, Fachanwendern, die diese Prozesse verwalten und kontrollieren
werden.
Das zweite wichtige Ziel war zu gewährleisten, dass Sprachen, die für die Ausführung
der Geschäftsprozesse entwickelt wurden, wie BPEL4WS (Business Process Execution
Language for Web Services) [ACD+ 03] und BPML (Business Process Modeling Language)
[Ark02], mit einer gemeinsamen Notation visualisiert werden konnten.
BPMN besteht aus einem Diagramm, genannt Business Process Diagram (BPM), welches als einfach zu benutzen und zu verstehen entworfen wurde, bietet aber die Möglichkeit, komplexe Geschäftsprozesse zu modellieren. Es basiert auf der Technik des Aufstellens von Flussdiagrammen, zugeschnitten für die Erzeugung von grafischen Modellen der
Geschäftsprozesshandlungen. Ein Modell des Geschäftsprozesses ist dementsprechend ein
Netzwerk von grafischen Objekten, die als Aktivitäten aufgefasst werden, und Flusssteuerungselementen, die die Abfolge ihrer Ausführung bestimmen.
Um den Ablauf eines Geschäftsprozesses zu modellieren, müssen Ereignisse modelliert
werden, um einen Prozess zu starten; die Prozesse, die ausgeführt werden und die Endergebnisse des Prozessablaufs. Geschäftsentscheidungen und Ablaufverzweigung werden
durch Gateways modelliert. Weiterhin kann ein Prozess Subprozesse enthalten, die grafisch mit einem anderen Business Process Diagram dargestellt werden können, verbunden
durch einen Hyperlink mit dem Prozesssymbol. Ist ein Prozess in Subprozesse nicht unterteilt, wird er als ein Task aufgefasst - ein Prozess der niedrigsten Ebene.
Die grafischen Elemente, die das Diagramm bilden, sind voneinander unterscheidbar und
verwenden die Formen, die den meisten Modellierern vertraut sind. So werden die Aktivitäten als Rechtecke und die Entscheidungen als Rauten dargestellt. Innerhalb der
Grundkategorien der Elemente können zusätzliche Variationen und Informationen hin-
2 Analyse bestehender visueller Sprachen zur Modellierung von Geschäftsprozessen
15
zugefügt werden, um die Forderung nach der Komplexität aufrechtzuerhalten, ohne das
Aussehen des Diagramms dramatisch zu ändern. Es gibt auch spezielle Notationen, um
botschaftsbezogene Ereignisse und das Versenden der Botschaften zwischen den Organisationen zu beschreiben. [Whi04a] Die vier Grundkategorien der Elemente sind:
• Flussobjekte (Flow Objects)
• Verbindungsobjekte (Connecting Objects)
• Verantwortlichkeitsbereich (Swimlanes)
• Artefakte (Artifacts)
Bei der tieferen Geschäftsanalyse kann spezifiziert werden, “wer macht was”, indem die
Ereignisse und Prozesse in schattierte Bereichte, genannt Pools, platziert werden. Diese
Bereiche zeigen an, wer einen Prozess ausführt. Im weiteren kann ein Pool in Lanes aufgeteilt sein. Ein Pool stellt typischerweise eine Organisation dar und ein Lane eine Abteilung
in dieser Organisation.
Im Folgenden wird ein näherer Blick auf diese Elemente gegeben.
Flussobjekte
Ein Business Process Diagramm hat einen kleinen Satz von Kernelementen, den Flussobjekten, so dass die Modellierer keine große Anzahl von verschiedenen Formen zu erlernen
und zu erkennen haben.
• Ereignis Ein Ereignis wird durch einen Kreis dargestellt und bedeutet ein Geschehnis im Laufe eines Geschäftsprozesses. Die Ereignisse beeinflussen den Prozessablauf
und haben gewöhnlich eine Ursache (Trigger) oder eine Wirkung (Resultat). Ereignisse sind ungefüllte Kreise und erlauben interne Markierer zur Unterscheidung
verschiedener Trigger und Resultate. Es gibt drei Typen von Ereignissen, bezogen
auf den Zeitpunkt, wann sie den Ablauf beeinflussen: Start, Zwischenereignis und
Ende (Abbildung 2.5).
A)
B)
C)
Bild 2.5: Typen der Ereignisse. a) Startereignis b) Zwischenereignis c) Endereignis
2 Analyse bestehender visueller Sprachen zur Modellierung von Geschäftsprozessen
16
• Aktivität Eine Aktivität wird durch ein Rechteck mit gerundeten Ecken repräsentiert und ist ein allgemeiner Ausdruck für den Arbeitsgang, der von einem Betrieb
ausgeführt wird. Eine Aktivität kann atomar oder nicht-atomar (zusammengesetzt)
sein. Die Typen der Aktivitäten sind Task und Sub-Prozess. Ein Sub-Prozess ist
ausgezeichnet durch ein kleines Plus-Zeichen im unteren Mittelteil der Form (Abbildung 2.6).
Bild 2.6: Aktivität
• Gateway Ein Gateway wird durch die Rautenform repräsentiert und zur Steuerung der Abzweigungen und Zusammenlaufen des Sequenzflusses (Abbildung 2.7)
benutzt. Es bestimmt somit traditionelle Entscheidungen sowie Gabelung, Vereinigung und Verbindung der Pfade. Interne Markierer deuten den Typ der Steuerung
des Verhaltens an.
Bild 2.7: Gateway
Verbindungsobjekte
Die Flussobjekte werden in einem Diagramm zusammen verbunden und erzeugen die
skelettartige Grundstruktur eines Geschäftsprozesses. Es gibt drei Verbindungsobjekte,
die diese Funktion gewährleisten. Es sind:
• Sequenzfluss Ein Sequenzfluss wird durch eine durchgezogene Linie mit solider
Pfeilspitze dargestellt und benutzt, um die Reihenfolge, mit welcher die Aktivitäten
in einem Prozess ausgeführt werden, zu zeigen (Abbildung 2.8).
Bild 2.8: Sequenzfluss
2 Analyse bestehender visueller Sprachen zur Modellierung von Geschäftsprozessen
17
• Nachrichtenfluss Ein Nachrichtenfluss wird durch eine gestrichelte Linie mit einer
ungefüllten Pfeilspitze dargestellt und benutzt, um einen Nachrichtenfluss zwischen
zwei separaten Prozessteilnehmern (Geschäftsunternehmen oder Geschäftsrollen),
die die Nachrichten senden und erhalten, zu zeigen (Abbildung 2.9).
Bild 2.9: Nachrichtenfluss
• Assoziation Eine Assoziation wird durch eine gepunktete Linie mi einer Linienpfeilspitze dargestellt und benutzt, um Daten, Texte und andere Artefakten mit
Flussobjekten zu assoziieren. Assoziationen werden auch zum Anzeigen der Eingaben und Ausgaben der Aktivitäten verwendet (Abbildung 2.10).
Bild 2.10: Assoziation
Für die Modellierer, die eine niedriege Ebene der Präzision beim Erzeugen der Prozessmodelle für Dokumentation und Kommunikation erfordern, gewährleisten die Kernelemente
zusammen mit den Verbindungen die Möglichkeit, verständliche Diagramme leicht zu erzeugen.
Für die Modellierer, die eine höhere Ebene der Präzision beim Erzeugen der Prozessmodelle erfordern, die zum Gegenstand einer detaillierten Analyse oder vom Geschäftsprozessmanagementsystem geleitet werden, können zu den Kernelementen zusätzliche Details
hinzugefügt und durch interne Markierer angezeigt sein.
Swimlanes
Viele Methodologien der Prozessmodellierung verwenden den Konzept von Swimlanes als
einen Mechanismus zur Organisierung der Aktivitäten in separate visuelle Kategorien, um
verschiedene funktionale Fähigkeiten oder Zuständigkeiten zu erläutern [RO03]. BPMN
unterstützt Swimlanes mit zwei Grundkonstrukten. Die Typen der Swimlane-Objekten in
einem Geschäftsprozessdiagramm sind:
• Pool Ein Pool repräsentiert einen Teilnehmer in einem Prozess. Er tritt auch als
ein grafischer Container zur Aufteilung eines Satzes von Aktivitäten von anderen
Pools auf.
2 Analyse bestehender visueller Sprachen zur Modellierung von Geschäftsprozessen
18
• Lane Ein Lane ist eine Untergliederung innerhalb eines Pools und erstreckt sich
für die ganze Länge des Pools, entweder senkrecht oder waagerecht. Lanes werden
a)
Name
b)
Name
Name Name
verwendet, um die Aktivitäten zu organisieren und zu kategorisieren.
Bild 2.11: Swimlanes. a) Pool b) Lane vgl. [pre10]
Pools werden verwendet, wenn das Diagramm zwei separate Geschäftsunternehmen oder
Teilnehmer einschliesst und sie im Diagramm physikalisch getrennt sind. Die Aktivitäten
innerhalb der separaten Pools werden als eigenständige Prozesse betrachtet. Deshalb kann
ein Sequenzfluss die Grenzen eines Pools nicht durchqueren. Ein Nachrichtenfluss wird definiert als ein Mechanismus zum Anzeigen der Kommunikation zwischen zwei Teilnehmern
und muss deswegen Verbindungen zwischen zwei Pools (oder zwischen Teilnehmern in-
Patient
nerhalb des Pools) herstellen. Lanes sind näher auf die traditionelle Methodologie der
Send Doctor
Request
Recive Appl.
Send
Symptoms
5) go see doctor
Doctor‘s Office
1) I want to see doctor
Receive
Doctor
Request
6) I feel sick
Send Appl.
Receive
Symptoms
Receive
Prescription
Pickup
8) Pickup you medicine
and you can leave
Send
Prescription
Pickup
Receive
Medicine
Send Medicine
Request
10) Here is my medicine
9) Need my medicine
Receive
Medicine
Request
Send
Medicine
Bild 2.12: Beispiel eines Diagramms mit Pool vgl. [pre10]
Modellierung von Swimlane-Prozessen bezogen. Die Lanes werden oft benutzt, um die
Aktivitäten, die mit einer spezifischen Betriebsfunktion oder Rolle assoziiert sind, abzugrenzen [RO03]. Ein Sequenzfluss kann die Grenzen der Lanes innerhalb eines Pools
überschreiten, ein Nachrichtenfluss aber kann zwischen Flussobjekten in den Lanes desselben Pools nicht angewandt werden.
Administration
2 Analyse bestehender visueller Sprachen zur Modellierung von Geschäftsprozessen
19
A
Sub. Process
Management
Prepare PO
Web Server
Approve
Request
Dispatch to
Approver
Bild 2.13: Ein Prozess mit Lanes
Artefakte
BPMN war entwickelt, um den Modellierern und den Modellierungstools Flexibilität in der
Erweiterung der Grundnotation und Gewährleistung der Fähigkeit zum zusätzlichen, der
spezifischen Modellierungsstuation angemessenen Kontext, zu erlauben. Es können beliebig viele Artefakte einem Diagramm zugefügt sein, soweit erforderlich für den Kontext des
zu modellierenden Geschäftsprozesses. In der aktuellen Version der BPMN-Spezifikation
[omg09] sind drei Typen der Geschäftsprozessdiagramm-Artefakte vordefiniert:
• Datenobjekt Datenobjekte sind Mechanismen, die zeigen, wie Daten von den Aktivitäten gefordert oder erzeugt werden. Sie sind mit den Aktivitäten durch Assoziationen verbunden.
• Gruppe Eine Gruppe wird durch ein Rechteck mit gerundeten Ecken dargestellt,
gezeichnet mit gestrichelter Linie. Die Gruppierung kann zwecks Dokumentation
oder Analyse verwendet werden, beeinflusst aber nicht den Sequenzfluss.
• Annotation Annotationen sind ein Mechanismus für den Modellierer, zusätzliche
textuelle Information dem Leser eines BPMN-Diagramms zu gewährleisten.
Text annotation allows
a modeler to provide
additional information
Name
[State]
A)
B)
C)
Bild 2.14: Artefakte. a) Datenobjekt b) Gruppe c) Annotation
2 Analyse bestehender visueller Sprachen zur Modellierung von Geschäftsprozessen
20
Modellierer können ihre eigenen Typen von Artefakten erzeugen, die in weitere ergänzt
werden. Dennoch wird die Grundstruktur des Prozesses, wie sie mit den Aktivitäten,
Gateways und dem Sequenzfluss bestimmt ist, mit dem Hinzufügen von den Artefakten
Web Server
Management
Administration
ins Diagramm nicht geändert.
Purchase Info
Prepare PO
Approval
Request
E-Mail
Approve
Request
This
activities can
be started at
the same time
Bild 2.15: Ein Prozess mit Datenobjekt, Gruppe und Annotation
2.4
Vergleich von BPMN und UML
UML ist eine Sprache, die den Entwicklern hilft, Modelle von den Softwaresystemen zu
spezifizieren, zu visualisieren und zu dokumentieren. Sie ist sehr stark an die Systemarchitekten und Softwareingenieure gerichtet und wurde als Mittel entwickelt, den Prozess
der Softwareentwicklung sukzessiv zu gestalten, vom Architekturdesign bis zur Anwendungsimplementation für die Nutzung in technischen Fachkreisen.
BPMN ist an die Geschäftsanalytiker, Systemarchitekten und Softwareingenieure gerichtet. Sie wurde entwickelt als Methode, den gesamten Entwicklungsprozess des Geschäftslebenszykluses ab dem Prozessentwurf sukzessiv zu gestalten, was in den Geschäftsfachkreisen durchgeführt wird.
BPNM ist UML insofern verwandt, dass sie eine graphische Notation für Geschäftsprozesse
definiert, die den UML-Verhaltensdiagrammen ähnlich ist. Jedoch haben BPMN und UML
sehr unterschiedliche Ansätze zur Modellierung der Geschäftsprozesse.
2 Analyse bestehender visueller Sprachen zur Modellierung von Geschäftsprozessen
21
UML bietet einen objekt-orientierten Ansatz für die Modellierung der Anwedungen,
während BPMN einen prozess-orientierten Ansatz nimmt. Die meisten UML-Methoden
erfordern zuerst das Erstellen von Objekten unter Benutzung der statischen Strukturdiagrammen. Erst danach werden dynamische Verhaltensdiagramme gebildet, um zu zeigen, wie die Objekte zusammenwirken. Diese Methode der Modellierung ist den meisten
Geschäftsanalytikern fremd.
BPMN bietet einen prozess-orientierten Ansatz, welcher natürlich und intuitiv für die
Geschäftsanalytiker ist. Mit BPMN werden zuerst die Kontroll- und Nachrichtenflüsse
der Prozesse modelliert. Ein Objektmodell des Prozesses wird eher implizit als explizit
definiert. BPNM bietet auch die Option, Geschäftsobjekte explizit zu modellieren, die
durch Geschäftsdienste im Prozessfluss dargelegt werden können.
UML ist ein Satz von Diagrammen, die sich aus den bewährten Kollektivverfahren verschiedener Anwender ergeben haben [Whi06]. Das bedeutet, dass die Diagramme eine
Ansammlung darstellen, aber nicht speziell dazu erschaffen wurden, um miteinander zusammenzuwirken. Im Gegensatz dazu definiert BPMN einen einfachen Typ von Diagrammen, welcher vielfache Ansichten hat, hergeleitet aus demselben zu Grunde liegenden
Meta-Modell der Prozessausführung. Das Ergebnis ist, dass die Implementation in einer Geschäftsprozessausführungssprache lediglich zu einer anderen logischen Ansicht des
Prozesses wird.
Schließlich definiert UML kein Meta-Modell für die Ausführung der Geschäftsprozesse,
die damit modelliert wurden. Stattdessen muss jedes Ausführungsmetamodell unter Benutzung von modellgetriebener Architektur (engl.: Model Driven Architecture, MDA)
[Sch08] definiert werden. BPMN basiert auf dem Metamodell der Prozessausführung von
BPML und erfordert somit keine zusätzlichen Schritte für die Modellierung vollständig
ausführbarer Prozesse.
In Zukunfr werden BPMN und UML sehr wahrscheinlich koexistieren [Whi06]. Es wird
Benutzer im technischen Bereich geben, die nicht beabsichtigen, BPMN als letztes Mittel
der Entwicklung zu verwenden und weiter mit UML arbeiten wollen. BPMN kann dann
benutzt werden, um Lösungen anzusteuern, die direkt auf einem Geschäftsprozessmanagementserver (BPMS) laufen oder als ein Front-End der Geschäftsanalyse für die nachfolgende Systementwicklung mit UML verwendet werden. Unter diesem Szenario würden
die UML-Benutzer die Geschäftsprozesse lediglich als einen anderen Komponententyp betrachten.
2 Analyse bestehender visueller Sprachen zur Modellierung von Geschäftsprozessen
2.4.1
22
BPMN und UML-Aktivitätendiagramm
Das Ziel dieses Abschnitts ist zu untersuchen, wie zwei Modellierungsnotationen, das
BPMN-Geschäftsprozessdiagramm und das UML 2.0-Aktivitätendiagramm die Muster
des Arbeitsablaufs graphisch darstellen können. Für jedes Muster werden die beiden Notationen in Hinblick darauf verglichen, wie gut sie die Muster behandeln. Der Mittelpunkt
des Vergleichs stellt sowohl technisch als auch visuell jede Notation der Muster vor.
Ablaufmuster: Sequenz
Das Sequenzmuster ist definiert als eine geordnete Folge von Aktivitäten, wobei eine
Aktivität startet, nachdem die vorhergehende Aktivität beendet ist.
Geschäftsprozessdiagramm Ein Geschäftsprozessdiagramm definiert dieses Muster
als eine Folge von Aktivitäten verbunden durch einen Sequenzfluss (Abbildung 2.16).
Die Richtung der Pfeilspitzen des Sequenzflusses bestimmt den Ablauf der Sequenz. Das
Verhalten dieses Musters kann durch eine Begriffsmarke beschrieben werden, welche sich
durch den Sequenzfluss vom Ausgangsobjekt zum Zielobjekt bewegt, abhängig von der
Richtung der Pfeile. Wenn bei diesem Muster eine Aktivität beendet ist, läuft die Marke
durch den Sequenzfluss von dieser Aktivität zur nächsten Aktivität in der Sequenz. Es
gibt keine Bedingtheit oder eine andere Art der Kontrolle über die Marke. In BPMN wird
jede auf den Fluss der Marken gesetzte Kontrolle durch eine Raute kennzeichnet, entweder
in einem Gateway-Objekt oder einem bedingten Sequenzfluss.
A
B
C
Bild 2.16: Sequenz - Geschäftsprozessdiagramm. vgl. [Whi06]
Aktivitätendiagramm Das UML-Aktivitätendiagramm definiert dieses Muster als eine Folge von Aktivitäten verbunden durch einen Kontrollfluss (Abbildung 2.17). Die Richtung der Pfeilspitzen des Kontrollflusses bestimmt den Ablauf der Sequenz. So wie beim
Geschäftsprozessdiagramm läuft die Marke beim Beenden einer Aktivität durch den Kontrollfluss von dieser Aktivität zu der nächsten Aktivität in der Sequenz.
Vergleich Es gibt keinen großen Unterschied zwischen BPMN und UML im Erstellen
der Diagramme für Sequenzmuster. Beide Notationen verwenden gerundete Vierecke, um
2 Analyse bestehender visueller Sprachen zur Modellierung von Geschäftsprozessen
A
B
23
C
Bild 2.17: Sequenz - Aktivitätendiagramm. vgl. [Whi06]
Aktivitäten darzustellen. Der genaue Grad der Rundung für die Ecken der Vierecke liegt
an dem Modellierer oder dem Tool-Anbieter. Die beiden Notationen benutzen durchgezogene, gerichtete Linien, um die Richtung des Flusses anzuzeigen. Jedoch sind die
Pfeilspitzen in den beiden Standards verschieden. UML verwendet Linienpfeilspitze für
den Kontrollfluss und den Fluss von Standardobjekten, während BPMN solide Pfeilspitze
für den Sequenzfluss benutzt.
Ablaufmuster: parallele Spaltung
Das Muster für die parallele Spaltung ist definiert als ein Mechanismus, welcher es erlaubt, die Aktivitäten gleichzeitig anstatt hintereinander auszuführen. Ein einzelner Pfad
durch den Prozess wird in zwei oder mehrere Pfade gesplittet, so dass zwei oder mehrere
Aktivitäten zu gleicher Zeit starten.
Geschäftsprozessdiagramm Ein BPMN- Geschäftsprozessdiagramm liefert drei Mechanismen für das Erzeugen von Mustern für parallele Spaltung. Der erste Mechanismus
erlaubt, dass ein Flussobjekt zwei oder mehr ausgehende Sequenzflüsse haben kann (Abbildung 2.18). Ein spezielles Flusskontrollobjekt zum Aufspalten des Pfades ist nicht erforderlich, weil es als ein nicht kontrollierter Fluss betrachtet wird. Der Fluss verläuft
somit jeden Pfad hinunter ohne irgendwelche Abhängigkeiten oder Bedingungen, d.h. es
gibt kein Gateway, welches den Fluss kontrolliert. Eine Marke wird für jeden ausgehenden Sequenzfluss erzeugt. Ein aufgespalteter Sequenzfluss kann von einem Task, einem
Sub-Prozess oder einem Startereignis gebildet werden.
B
A
Parallel Splitt
Uncontrolled Flow
C
Bild 2.18: Parallele Spaltung - Geschäftsprozessdiagramm. Mechanismus 1. vgl.
[Whi06]
2 Analyse bestehender visueller Sprachen zur Modellierung von Geschäftsprozessen
24
Der zweite Mechanismus benutzt ein paralleles Gateway (eine Raute mit einem PlusZeichen als interner Marker, siehe Abbildung 2.19). Nachdem die Marke das Gateway
erreicht hat, wird eine Marke unverzüglich in jeden ausgehenden Sequenzfluss gesendet.
Es gibt andere Situationen, wo ein paralleles Gateway erforderlich sein könnte, wie z.B.
eine parallele Spaltung, die einer ausschließenden Wahl folgt (siehe Abbildung 2.25 für
das Beispiel einer ausschließenden Wahl.)
B
A
C
Parallel Splitt
Forwarding
Gateway
Bild 2.19: Parallele Spaltung - Geschäftsprozessdiagramm. Mechanismus 2. vgl.
[Whi06]
Es kann ein dritter Mechanismus für das Erzeugen von Mustern der parallelen Spaltung
verwendet werden. Wenn ein Prozess oder Sub-Prozess kein Startereignis besitzt, welches
optional ist, dann startet jede Aktivität, die keine eingehenden Sequenzflüsse hat, wenn
der Sub-Prozess startet. Es wird eine Marke für jede gestartete Aktivität erstellt. Die
Hauptidee besteht darin, dass der Modellierer eine parallele Box, wie in Abbildung 2.20
zu sehen ist, und eine parallele Situation mit einer kompakten und visuell deutlichen
Technik erzeugen kann.
B
A
Parallel Splitt
Uncontrolled Flow
Applies to Start
Events
C
Bild 2.20: Parallele Spaltung - Geschäftsprozessdiagramm. Mechanismus 3. vgl.
[Whi06]
Aktivitätendiagramm Das UML-Aktivitätendiagramm benutzt einen Zweigknoten,
um einen Satz von parallelen Pfaden zu erzeugen (ein senkrechter oder waagerechter Balken - sieh Abbildung 2.21). Der Balken zeigt an, dass der gesamte vom Balken ausgehende
2 Analyse bestehender visueller Sprachen zur Modellierung von Geschäftsprozessen
25
Kontrollfluss einen Satz von parallelen Flüssen erzeugt. Eine Marke wird für jeden ausgehenden Kontrollfluss erstellt. Die Zielaktivitäten für jeden dieser Flüsse werden verfügbar
sein, um zur gleichen Zeit anzufangen.
B
A
C
Bild 2.21: Parallele Spaltung - Aktivitätendiagramm. vgl. [Whi06]
Vergleich Die Mechanismen, die die Muster für parallele Spaltung bereitstellen, sind
bei den beiden Notationen verschieden. BPMN bietet viel einfachere Mechanismen mit
mehrfach ausgehendem Sequenzfluss und der parallelen Box. Wenn ein Kontrollobjekt
benötigt oder erwünscht wird, dann ist ein paralleles Gateway vorhanden. UML erfordert, dass ein graphisches Objekt, ein Zweigknoten, die parallele Spaltung erzeugt. Im
Allgemeinen ist der Ansatz für den Kontrollfluss in beiden Notationen unterschiedlich.
BPMN verwendet eine einzige Form, die Raute, um jede Art von Kontrolle oder Bedingung auf dem Ablauf der Marken zwischen den Aktivitäten darzustellen. Interne Marker
zeigen den genauen Typ der Kontrolle an (z.B. alternative oder parallele Spaltung). Die
Rautenform wurde gewählt, weil sie weitgehend als ein Entscheidungsobjekt beim Erstellen der Flussdiagramme anerkannt ist. BPMN sieht einen kleineren Satz von Kernobjekten
der Modellierung vor. UML benutzt zwei verschiedene Typen von Objekten (Raute und
Balken), um die Kontrolle über dem Markenfluss darzustellen. Das gewährleistet eine
leichtere Unterscheidung zwischen den zwei Grundtypen der Kontrolle (alternativ und
parallel), wenn aber eine komplexere Kontrolle gefordert wird, welche sowohl alternative
als auch parallele Verhalten enthält, wird diese Unterscheidung weniger deutlich.
Ablaufmuster: Synchronisation
Das Synchronisationsmuster vereinigt Pfade, die durch ein Muster für parallele Spaltung
erzeugt wurden. Alle Aktivitäten innerhalb der Flüsse müssen vollendet werden, bevor
der Prozess fortfahren kann. Das ist die Synchronisation der parallelen Pfade.
Geschäftsprozessdiagramm In BPMN gibt es zwei Mechanismen für die Synchronisationsmuster. Der erste Mechanismus ist mit der Anwendung von parallelen Gateways
2 Analyse bestehender visueller Sprachen zur Modellierung von Geschäftsprozessen
26
verbunden (siehe Abbildung 2.22). Dieses Gateway wird auch bei den Mustern für parallele
Spaltung eingesetzt und kann die beiden Funktionen gleichzeitig ausführen. Das Gateway
empfängt den mehrfachen eingehenden Sequenzfluss und wartet darauf, dass die Marken
von jedem Fluss ankommen, bevor eine einzige Marke nach dem Gateway fortfährt. Dieser
Mechanismus wird für die beiden ersten Typen der Muster für parallele Spaltung verwendet. Ein Gateway muss in diesem Fall benutzt werden, weil der Prozessfluss kontrolliert
und synchronisiert wird. Der zweite Mechanismus ist der abschließende Teil der Technik
A
C
B
Synchronization
Joining Gateway
Bild 2.22: Synchronisation - Geschäftsprozessdiagramm. Mechanismus 1. vgl. [Whi06]
der parallelen Box, wie in der Abbildung 2.23 gezeigt. Wenn ein Prozess oder ein SubProzess kein Endereignis hat, dann endet der Sub-Prozess, wenn alle Aktivitäten beendet
sind, die keine ausgehenden Sequenzflüsse haben. Der Sub-Prozess wird nicht vollendet,
bis alle interne Aktivitäten vollendet sind. Dann fährt eine Marke nach dem Sub-Prozess
innerhalb des gesamten Prozesses fort. Der Mechanismus der parallelen Box ist geradezu eine Teilmenge des allgemeinen Mechanismus für das Beenden eines Sub-Prozesses.
Gibt es parallele Pfade innerhalb eines Sub-Prozesses, so kann jeder dieser Pfade in einem
einzelnen deterministischen Endereignis enden. Der Sub-Prozess wird nicht vollendet, bis
alle parallelen Pfade das Endereignis nicht erreicht haben. Das synchronisiert den Fluss,
welcher sich weiter zum Prozess auf einer höheren Ebene bewegt.
A
C
B
Synchronization
Applies to End
Events
Bild 2.23: Synchronisation - Geschäftsprozessdiagramm. Mechanismus 2. vgl. [Whi06]
Aktivitätendiagramm Das UML-Aktivitätendiagramm verwendet einen Verbindungsknoten, um einen Satz von parallelen Pfaden zu vereinigen (Abbildung 2.24). Der
2 Analyse bestehender visueller Sprachen zur Modellierung von Geschäftsprozessen
27
Balken sieht genauso wie der Zweigknoten aus und tatsächlich kann ein einziger Balken
die beiden Funktionen ausführen. Der Verbindungsbalken deutet an, dass die Marken
von allen in den Balken eingehenden Kontrollflüssen ankommen müssen. Dann wird eine
einzelne Marke nach dem Balken fortsetzen. Ein anderer Mechanismus, der einem Akti-
A
C
B
Bild 2.24: Synchronisation - Aktivitätendiagramm. vgl. [Whi06]
vitätendiagramm zur Verfügung steht, benutzt eine Sub-Aktivität. Gibt es parallele Pfade
innerhalb einer Sub-Aktivität, kann jeder dieser Pfade in einem gesonderten deterministischen Endknoten des Flusses enden. Der Sub-Prozess wird nicht vollendet sein, bis
alle parallelen Pfade einen Endknoten des Flusses nicht erreichen. Das synchronisiert den
Fluss, welcher sich weiter zum Prozess auf einer höheren Ebene bewegt.
Vergleich Die Mechanismen für die Bereitstellung des Synchronisationsmusters sind
im Grunde dieselben für die beiden Notationen, sehen aber unterschiedlich aus. Ein
Geschäftsprozessdiagramm verwendet ein paralleles Gateway und ein Aktivitätendiagramm verwendet einen Verbindungsknoten. Die beiden Notationen bieten auch synchronisiertes Verhalten für die Vollendung eines Sub-Prozesses. Die entsprechenden Vorteile
der Flusskontrollobjekte wurden beim Vergleich des Musters für eine parallele Spaltung
diskutiert.
Ablaufmuster: Ausschließende Wahl
Das Muster für ausschließende Wahl wird als eine Stelle in einem Prozess definiert, wo
der Fluss in zwei oder mehrere ausschließende alternative Pfade geteilt wird. Das Muster
ist ausschließend, weil nur einer der alternativen Pfade für die Fortsetzung des Prozesses
gewählt werden kann.
Geschäftsprozessdiagramm Da ein zusätzlicher Kontrollmechanismus benötigt wird,
um das Muster für ausschließende Wahl zu erzeugen, benutzt BPMN ein Gateway. Für
dieses Muster wird ein ausschließendes datenbasiertes Gateway verwendet (eine Raute,
2 Analyse bestehender visueller Sprachen zur Modellierung von Geschäftsprozessen
28
sieh Abbildung 2.25). Der vom Gateway ausgehende Sequenzfluss enthält boolesche Ausdrücke, die ausgewertet werden, um zu bestimmen, welcher Sequenzfluß verwendet werden
muss, um den Prozess fortzusetzen. Wenn eine Marke am Gateway ankommt, werden die
Ausdrücke ausgewertet (in einer festgelegten Weise) und für den ersten Ausdruck, der als
wahr bestimmt wurde, wird der entsprechende Sequenzfluß gewählt und die Marke fährt
diesen Pfad fort. Nur eine Marke verlässt das Gateway für jede Marke, die am Gateway
ankommt.
Condition 1
B
A
Condition 2
C
Bild 2.25: Ausschließende Wahl - Geschäftsprozessdiagramm. vgl. [Whi06]
Aktivitätendiagramm Das UML-Aktivitätendiagramm benutzt einen Entscheidungsknoten, um einen Satz von ausschließenden alternativen Pfaden zu erzeugen (Abbildung
2.26). Der vom Entscheidungsknoten ausgehende Kontrollfluss enthält boolesche Ausdrücke, die ausgewertet werden, um zu bestimmen, welcher Kontrollfluß verwendet werden
muss, um den Prozess fortzusetzen. Wenn eine Marke am Entscheidungsknoten ankommt,
werden die Ausdrücke ausgewertet (in einer nicht festgelegten Weise) und für den Ausdruck, der als wahr bestimmt wurde, wird der entsprechende Kontrollfluß gewählt und
die Marke fährt diesen Pfad fort. Nur eine Marke verlässt den Entscheidungsknoten für
jede Marke, die am Knoten ankommt.
B
A
C
Bild 2.26: Ausschließende Wahl - Aktivitätendiagramm. vgl. [Whi06]
Vergleich Dieses Muster ist ein Beispiel dafür, dass die beiden Notationen das Verhalten
auf nahezu dieselbe Weise darstellen. Die beiden Notationen benutzen eine Raute, um
2 Analyse bestehender visueller Sprachen zur Modellierung von Geschäftsprozessen
29
diese Art der Entscheidung darzustellen.
Ablaufmuster: einfaches Mischen (simple merge)
Das Muster für einfaches Mischen wird definiert als eine Stelle in einem Prozess, in dem
ein Satz von alternativen Pfaden in einen einzigen Pfad vereinigt wird.
Geschäftsprozessdiagramm Das Muster für einfaches Mischen ist ein anderes Beispiel für einen nicht kontrollierten Fluß innerhalb BPMN. Das heißt, eine Marke kann
zwischen zwei Aktivitäten ohne jeden eingreifenden Kontrollmechanismus (Gateway) verlaufen. Mehrfache eingehende Sequenzflüsse sind erlaubt (Abbildung 2.27), weil ein Verhalten angenommen wird, dass nur von einem der eingehenden Sequenzflüsse erwartet
wird, eine Marke zur Ausführungszeit zu haben. Wenn die Marke ankommt, startet die
Aktivität unverzüglich. Ein ausschließendes Gateway kann auch verwendet werden, um
Condition 1
B
A
D
C
Condition 2
Bild 2.27: Einfaches Mischen - Geschäftsprozessdiagramm. Variante 1. vgl. [Whi06]
alternative Pfade zu mischen (siehe Abbildung 2.28). Modellierer können es als ein bewährtes Verfahren benutzen. Wenn eine Marke am Gateway ankommt, und nur eine erwartet
wird, verläuft sie sofort den ausgehenden Sequenzfluß hinunter.
Condition 1
B
A
D
Condition 2
C
Single Merge
Merging
Gateway
Bild 2.28: Einfaches Mischen - Geschäftsprozessdiagramm. Variante 2. vgl. [Whi06]
Aktivitätendiagramm Das UML-Aktivitätendiagramm verwendet einen Mischknoten, um einen Satz alternativer Pfade zusammenfließen zu lassen (Abbildung 2.29). Die
2 Analyse bestehender visueller Sprachen zur Modellierung von Geschäftsprozessen
30
Raute sieht dabei genauso wie Entscheidungsknoten aus und, tatsächlich, eine einzige
Raute kann beide Funktionen ausführen. Wenn eine Marke am Knoten ankommt, verläuft
sie sofort den ausgehenden Kontrollfluß hinunter. Technisch gesehen ist ein Mischknoten
nicht erforderlich und mehrere eingehende Kontrollflüsse sind für eine Aktivität erlaubt,
doch es ist nicht als geeignete Methode für das Modellieren des Verhaltens der Aktivitätendiagramme angesehen.
Condition 1
B
A
D
Condition 2
C
Bild 2.29: Einfaches Mischen - Aktivitätendiagramm. vgl. [Whi06]
Vergleich Als Standardpraxis liefert ein Geschäftsprozessdiagramm einen einfacheren
Mechanismus für das Muster des einfachen Mischens: mehrere eingehende Sequenzflüsse.
Ein ausschließendes Gateway kann benutzt werden, wenn erwünscht, und das macht das
Geschäftsprozessdiagramm äquivalent der Lösung mit dem Aktivitätendiagramm.
2.4.2
Anwendung der Notationen zur Geschäftsprozessmodellierung
Der Vergleich der Modellierung von Ablaufmustern mittels Geschäftsprozessdiagramme
und Aktivitätendiagramme zeigt, dass die beiden Notationen die meisten Muster adäquat
modellieren können. Die einzige Ausnahme besteht darin, dass das Aktivitätendiagramm
keine adäquate graphische Darstellung für die Muster der verschachtelten parallelen
Abläufe hat, selbst wenn das dem Aktivitätendiagramm zugrunde liegende Metamodel
eine angemessene Struktur für das Erzeugen der Muster besitzt.
Die Tatsache, dass die beiden Notationen änliche Lösungen für die meisten Muster liefern,
zeigt wie nah die Notationen in ihrer Gestaltung sind. Die beiden benutzen viele gemeinsame Formen für dieselben Zwecke (z. B. gerundete Vierecke für Aktivitäten, Raupen für
Entscheidungen usw.). Es gibt einige Unterschiede in der Modellierung der Objektformen.
Dabei enthält BPMN wenigere Kernobjekte aber enthält weitere Objektvariationen, um
Komplexitäten zu beherrschen, die in den Modellierungsprozessen entstehen könnten. Ein
anderer Unterschied zwischen den beiden Diagrammen liegt häufig nur in der Terminolo-
2 Analyse bestehender visueller Sprachen zur Modellierung von Geschäftsprozessen
31
gie. So hat z.B. ein Aktivitätendiagramm einen Startknoten und ein Geschäftsprozessdiagramm ein Startereignis. Zusätzliche Unterschiede existieren, wenn Datenflüsse zwischen
den Aktivitäten betrachtet werden.
Die Ähnlichkeiten zwischen den Diagrammen bestehen deswegen, weil sie entwickelt wurden, um dasselbe Grundproblem zu lösen: Erstellen der Diagramme von den verfahrensorientierten Geschäftsprozessen. Die Unterschiede zwischen den beiden Diagrammen bestehen wegen der Zielbenutzer der Diagramme. Der Durchsatz von BPMN erfolgte vor
wenigen Jahren mit dem Ziel, eine Notation für die Benutzung durch Fachanwender zu
erzeugen. UML wurde vor mehreren Jahren durchgesetzt, um die Softwareentwicklung zu
standardisieren und das Aktivitätendiagramm wurde als Teil davon eingesetzt. Obwohl
die Entwicklung von UML 2.0 ein mehr konzentriertes Bestreben umfasste, das Aktivitätendiagramm in Hinblick auf dessen Benutzung unter Geschäftsleuten auszubauen,
ist es immer noch mehr technisch orientiert.
Kapitel 3
Abgrenzung bestehender
Ausführungssprachen
Geschäftsprozessmodellierungssprachen sind XML-basierte Meta-Sprachen, die als Mittel
zur Modellierung von Geschäftsprozessen in einem XML-Format benutzt werden. BPMN
wurde entwickelt, um verständliche graphische Darstellungen von Geschäftsprozessen zu
erstellen. Sie ist auch mit geeigneten Eigenschaften für graphische Objekte ausgestattet,
die die Erzeugung von Geschäftsprozessausführungssprachen möglich machen. Es sind
mehrere verschiedene Geschäftsprozessausführungssprachen vorgestellt worden. Die meisten von ihnen benutzen XML und bauen auf der Web Service Description Language
(WSDL) vom W3C-Standard auf. Die Spezifikation von BPMN schliesst in sich die Abbildung auf die Geschäftsprozessausführungssprache BPEL (Business Process Execution
Language) ein [Whi05], so dass die Techniken zur Einbettung der einzelnen Services in
einen Geschäftsprozess gegeben sind und die Wiederverwendbarkeit der Komponenten
erhöht ist. Eine andere Ausführungssprache, XPDL (XML Process Definition Language),
ist von der WfMC spezifiziert und in der Spezifikation wird die Abbildung von BPMN auf
XPDL ebenso definiert. Im Folgenden werden die beiden Ausführungssprachen, BPEL und
XPDL, vorgestellt und es wird auf die Besonderheiten der beiden Sprachen eingegangen.
3.1
BPEL
Bei der Abbildung eines BPMN-Diagramms auf BPEL muss die Entscheidung hinsichtlich
der Grundstruktur des BPEL-Dokumentes getroffen werden. BPMN-Diagramme können
in vielen Methodologien und für viele Zwecke verwendet werden, von der beschreibenden Modellierung auf einer höheren Ebene bis zur detaillierten Modellierung für die
3 Abgrenzung bestehender Ausführungssprachen
33
Prozessausführung. Wenn eines der Ziele des Prozessmodells die Definition der Prozessausführung ist, so muss das Prozessmodell mit einem Modellierungstool entworfen
werden, welches dafür entwickelt wurde. Das Diagramm allein wird all die Information,
die für die Erzeugung einer gültigen BPEL-Datei erforderlich ist, nicht anzeigen. Ein Diagramm mit all dieser Information wird zu unübersichtlich. BPMN-Diagramme sind dafür
vorgesehen, die Grundstruktur und den Fluss von Aktivitäten und Daten innerhalb eines
Geschäftsprozesses anzuzeigen. Deshalb ist ein Modellierungstool erforderlich, mit dem
zusätzliche Informationen über den Prozess erfasst werden können, die zur Erzeugung
einer ausführbaren BPEL-Datei notwendig sind.
3.1.1
Dokumentaufbau
In der Praxis werden gegenwärtig Konzepte für die informationstechnische Realisierung
partnerübergreifender Geschäftsprozesse entwickelt. Im Mittelpunkt dieser Konzepte steht
der Begriff des Services. Ein Service ist eine Menge von Aktivitäten, angeordnet in einer
Kontrollstruktur, z.B. einem Workflow. Für die Beschreibung der Kontrollstruktur eines Services wird die Sprache Business Process Execution Language for Web Services
(BPEL4WS, WS-BPEL) verwendet [ACD+ 03].
BPEL ist eine imperative Programmiersprache für die Beschreibung von Geschäftsvorgängen, die eine XML-Notation hat. BPEL unterscheidet zwischen der Spezifikation
von abstrakteren Geschäftsprotokollen und ausführbaren Prozessen. Beide Anwendungen
haben eine gemeinsame Schnittmenge von Sprachelementen, die den Grossteil von BPEL
ausmacht. Die Syntax wird je nach Anwendungsziel weiter spezifiziert.
Jede BPEL Beschreibung hat den folgenden Grundaufbau:
1
<process name ="ProcessName">
2
<partnerLinks>..</partnerLinks>
3
<variables>..</variables>
4
<correlationSets>..</correlationSets>
5
<faultHandlers>..</faultHandlers>
6
<compensationHandler>..</compensationHandler>
7
<eventHandlers>..</eventHandlers>
8
activity
9
</process>
Das Dokument besteht aus einem process-Element, welches mit dem name-Attribut den zu
spezifizierenden Geschäftsvorgang benennt. Bis auf eine Aktivität sind alle Kindelemente
3 Abgrenzung bestehender Ausführungssprachen
34
optional. BPEL unterscheidet zwischen den so genannten Basisaktivitäten und strukturellen Aktivitäten. Basisaktivitäten sind atomare Operationen, die elementare Effekte, wie
die Kommunikation mit anderen Diensten bereitstellen. Ihre XML-Elemente sind:
receive, reply, invoke, assign, throw, terminate, wait, empty, scope, compensate
Strukturelle Aktivitäten beschreiben die Ablaufreihenfolgen und Ablaufbedingungen ihrer gekapselten Elemente, welche einfache Basisaktivitäten oder weitere strukturelle Aktivitäten sein können. Erst sie erlauben die mächtige Komposition von Basisaktivitäten.
Strukturelle Aktivitäten in BPEL sind die Elemente:
sequence, switch, while, pick, flow
3.1.2
Umgebungen
Die globale Umgebung beinhaltet alle Elemente des Wurzelelements ‘process’. Unterumgebungen mit lokalem Namensraum lassen sich mit dem ‘scope’-Element bilden. Das scopeElement kann, bis auf das partnerLinks-Element, alle Elemente enthalten, die das processElement enthalten darf. Insbesondere lassen sich so Variablen lokal deklarieren oder die
Ausnahmebehandlung in der Zuständigkeit auf bestimmte Bereiche einschränken. Semantisch entspricht dies Bereichen, die in imperativen Programmiersprachen durch Klammersetzung entstehen.
Ein BPEL-Prozess basiert vor allem auf XML, einschließlich Nachrichten, die im BPELProzess ein- und ausgehen, Nachrichten, die mit externen Services ausgetauscht werden
und jede lokale Variable, die vom Fluß selbst benutzt wird. Die Typen für alle diese Nachrichten und Variablen sind mit XML-Schema definiert, gewöhnlich in der WSDL-Datei
für den Fluß selbst oder in den WSDL-Dateien für die Services, die er aufruft. Darum
sind alle Variablen in BPEL XML-Dokumente und jeder BPEL-Prozess wendet eine angemessene Menge seines Codes auf, um diese Variablen zu verarbeiten. Das beinhaltet
üblicherweise Datentransformation zwischen den Darstellungen, die für verschiedene Services erforderlich sind, sowie eine lokale Verarbeitung der Daten (z.B um die Ergebnisse
von verschiedenen Services-Aufrufen zusammenzuknüpfen).
Der Startpunkt für den Umgang mit den Daten in BPEL ist die <assign>-Aktivität, die
auf dem XPath-Standard aufbaut. XPath-Anfragen, Ausdrücke und Funktionen spielen
eine große Rolle in diesem Typ der Manipulation und es sind auch fortgeschrittene Methoden vorhanden, die die Benutzung von XQuery, XSLT oder JAVA (gewöhnlich um
komplexere Datentransformation oder -manipulation durchzuführen) einbeziehen.
3 Abgrenzung bestehender Ausführungssprachen
35
Die <assign>-Aktivität erlaubt, Daten von einer XML-Variablen zu anderen zu kopieren
oder den Wert eines Ausdrucks zu berechnen und in einer Variable zu speichern. Das
<copy>-Element innerhalb der Aktivität beschreibt die Quelle und das Ziel der Zuweisung
(was woher und wohin zu kopieren ist), welche vom kompatiblen Typ sein müssen. Die
formale Syntax in der BPEL-Spezifikation ist:
1
<assign standard-attributes>
2
standard-elements
3
<copy>+
4
from-spec
5
to-spec
6
</copy>
7
</assign>
Detailliert wird das im Folgenden erklärt. From-spec und to-spec spezifizieren typischerweise eine Variable oder Variablenteil:
1
<assign>
2
<copy>
3
<from variable="c1" part="address"/>
4
<to variable="c3"/>
5
</copy>
6
</assign>
3.1.3
BPEL4People
Die BPEL-Spezifikation richtet sich auf Geschäftsprozesse, deren Aktivitäten als Interaktionen mit Webdiensten angenommen werden, ohne jedes weitere vorausgesetzte Verhalten. Das Spektrum der Aktivitäten, die die Geschäftsprozesse allgemeiner Anwendung
bilden, ist jedoch viel breiter. Menschen nehmen oft an der Ausführung der Geschäftsprozesse teil und leiten neue Aspekte ein, wie Interaktion zwischen dem Prozess und der
Benutzerschnittstelle, und ziehen menschliches Verhalten in Betracht.
Das BPEL4People [CKM+ 09] ist ein Satz von Elementen, welche die BPEL-StandardElemente erweitern und eine Modellierung von menschlichen Interaktionen ermöglichen,
die von einfachen Rollenzuweisungen bis zu komplexen Szenarios wie Trennung der Aufgabenbereiche und Interaktionen einschließlich ad-hoc-Daten reichen.
Die menschlichen Aktivitäten werden als ein neuer Typ der Basisaktivitäten dargestellt,
welche die Spezifikation der menschlichen Interaktionen in den Prozessen auf einem di-
3 Abgrenzung bestehender Ausführungssprachen
36
rekten Weg erlauben. Die Implementation der menschlichen Aktivitäten kann eine InlineAufgabe oder eine autonome menschliche Aufgabe sein, definiert in der WS-HumanSpezifikation.
Die BPEL4People-Erweiterung ist auf solche Weise definiert, dass sie auf BPEL aufsetzt,
so dass ihre Funktionen mit den BPEL-Funktionen immer, wenn erforderlich, zusammengesetzt werden können.
3.1.4
Beziehungen zu anderen Spezifikationen
BPEL4People benutzt folgende Spezifikationen:
• WS-BPEL 2.0: BPEL4People erweitert das WS-BPEL-2.0-Prozessmodel und verwendet existierende Ressourcen von BPEL-2.0, solche wie für Datenbehandlung.
• WS-HumanTask 1.1: BPEL4People benutzt die Definition der menschlichen Aufgaben und Notifikationen und erweitert allgemeine menschliche Rollen und Zuordnungen eingeführt in WS-HumanTask 1.1.
• WSDL 1.1: BPEL4People benutzt WSDL für die Definition der Service-Schnittstelle.
• XML Schema 1.0: BPEL4People verwendet das Datenmodell von XML Schema.
• XPath 1.0: BPEL4People benutzt XPath als Standardsprache für Anfragen und
Ausdrücke.
3.2
XPDL
XML Process Definition Language (XPDL) ist eine standardisierte Sprache zur Abbildung von Geschäftsprozessen [FGI+ ]. XPDL ist ein weit verbreiteter Standard, welcher von vielen kommerziellen und Open Source Anwendungen unterstützt wird [Rüc08].
Sie wurde von der WfMC (Workflow Management Coalition) standardisiert und ist etwa so alt wie BPEL. Das Ziel bei der Entwicklung dieser Sprache war ein universeller Standard zum Austausch von Geschäftsprozessbeschreibungen zwischen unterschiedlichen Workflow-Engines. Seit der Version 2.0 (2005) wird BPMN unterstützt [HKM].
Die Sprache lässt sich grob als bestehend aus einer Menge von Standardsymbolen für
die graphische Beschreibung des Geschäftsablaufs und der Arbeitsablaufstruktur und einer unendlichen Menge von Erweiterungspunkten beschreiben. Eine Struktur, welche mit
Standardsymbolen beschrieben wird, ist für alle Workflow-Engines verständlich und bei
3 Abgrenzung bestehender Ausführungssprachen
37
den Erweiterungspunkten handelt es sich um die Strukturen für die jeweilige spezifische
Workflow-Engines-Umsetzung der Arbeitsprozesse. Da die Sprache recht umfangreich ist,
wird im Folgenden anhand eines kleinen Beispiels der Aufbau und die Funktionsweise der
Bäckerei
Sprache beschrieben.
Brötchen
backen
Brötchen
verkaufen
Kasse
abrechnen
Bild 3.1: Modellierung eines Geschäftsablaufs am Beispiel einer Bäckerei
3.2.1
Conformance Klasse
Allgemeine Modellrestriktionen bezüglich der Prozessmodellierung können in einer so
genannten Conformance Klasse gesetzt werden. Hierfür existieren zwei unabhängige in der Conformance Klasse definierte Kategorien: Graphkonformität und BPMNModellportabilitat.
Graph-Conformance
Es gibt drei Graph-Conformance Klassen mit folgenden Eigenschaften:
NON-BLOCKED
- keine Restriktionen bezüglich der modellierten Prozessablaufgraphen.
LOOP-BLOCKED
- Aktivitäten und Abläufe bilden einen azyklischen Graphen.
FULL-BLOCKED
- Zu jeder Gabelung existiert genau eine korrespondierende Verbindung und, umgekehrt,
zu jeder Verbindung existiert genau eine korrespondierende Gabelung.
BPMN Model Portability Conformance
BPMN kann sowohl für “abstrakte” Modellierung des Aktivitätenflusses als auch für ein
vollständig ausführbares Design verwendet werden. Viele Werkzeuge verwenden jedoch
BPMN für die abstrakte Modellierung, fügen aber noch ausführbare Elemente in den
spezifischen Eigenschaften der Aktivitäten hinzu. Eines der Ziele von XPDL ist die Unterstützung der Portabilität von abstrakten Aktivitätenflüssen zwischen den Werkzeugen.
3 Abgrenzung bestehender Ausführungssprachen
38
Das erfordert eine Trennung der Elemente und Attribute von BPMN, welche die Modellierung der Aktivitätenflüsse betreffen, von denjenigen, die das ausführbare Design betreffen.
Die Spezifikation von BPMN definiert diese Trennung nicht, bei XPDL wird sie dagegen
in Form von Klassen der Konformität zur Portabilität der BPMN-Modelle definiert. Im
Allgemeinen repräsentieren die Elemente des “abstrakten Modells” diejenigen BPMNKonstrukte, die im Geschäftsprozessdiagramm ausgedrückt werden, solche die den Typ
oder Subtyp des Flussobjekts definieren (z.B. Schleifen der Benutzertasks, gescheiterte
Subprozesse, ausschließende Gateways, Timerereignisse) oder nur Attribute einschließen,
die Subtyp, Label (Nameattribut) und eindeutige Identifizierer für das Objekt selbst und
die Zeiger auf andere Identifizierer im Diagramm spezifizieren. Elemente und Attribute, die Daten, Nachrichten oder andere Details der Implementation darstellen, sind aus
dem abstrakten Prozessmodell ausgelassen. In anderen Worten beschreibt das Modell das
“was” und “wann” des Prozessaktivitätsflusses und nicht das “wie” der Implementation
der Flussobjekte.
3.2.2
Metamodell
Damit das Mapping zwischen XPDL und BPMN einfacher verläuft, wurde ein Metamodell für XPDL erzeugt, bei welchem die Aktivitäten, Transitionen und weitere Elemente
direkt an BPMN angelehnt sind [Hei09]. Im Metamodell sind auch Swimlanes und Pools
enthalten, die für BPMN typisch sind und einzelne Akteure voneinander abgrenzen oder
gruppieren.
3.2.3
Teilnehmer
Teilnehmer (Participants) sind in XPDL Ressourcen, Organisationseinheiten, Rollen,
Menschen oder das System. In einem Bäckereibeispiel wären es Bäcker und Kassierer
und der XML-Eintrag hätte folgende Form:
1
2
<Participants>
<Participant Id="Becker">
3
<ParticipantType Type="ROLE"/>
4
<Description>Brötchen hersteller</Description>
5
</Participant>
6
<Participant Id="Kassierer">
7
...
8
</Participant>
9
</Participants>
3 Abgrenzung bestehender Ausführungssprachen
3.2.4
39
Pools & Lines
Innerhalb des Pools sind Lines entsprechend der BPMN Notation definiert. Lines innerhalb
eines Pools werden in eine XML-Darstellung verschachtelt abgebildet. Des Weiteren muss
einer Line jeweils eine ausführende Instanz zugeordnet werden. In dem Beispiel existiert
ein Bäckerei - Pool, welcher genau eine Swimmline enthält. Dies führt in dem vorgestellten
Beispiel zur folgenden XPDL-Darstellung:
1
2
3
<Pools>
<Pool Process=" 1 " Id=" 2 " Name="Bäckerei" BoundaryVisible="true">
<Lanes /><NodeGraphicsInfos>...</NodeGraphicsInfos>
4
</Pool>
5
...
6
</Pools>
3.2.5
Aktivitäten
Die Aktivitäten werden hier wiederum in Tasks, Subprozesse, Ereignisse und Gateways
unterteilt. Es entstehen dabei reduzierbare Graphen, deren Erzeugung durch Subprozesse
bzw. Blockaktivitäten stattfinden. Die Ausführung des Prozesses wechselt in den Startzustand des jeweiligen Subprozesses und kehrt nach dem Erreichen einer Austrittsaktivität
in den aufrufenden Prozess zurück. In den Aktivitäten können außerdem noch Implementierungen und ausgehende Transitionen enthalten sein. Dies ergibt für zuvor genanntes
Beispiel den folgenden XPDL-XML-Code:
1
<WorkflowProcess Id="Simple" Name="Simple">
2
<Activities>
3
<Activity ID = "Brötchen Backen">...<Activity>
4
<Activity ID = "Brötchen verkaufen">...<Activity>
5
<Activity ID = "Kasse abschliessen">
6
<Implementation>...</Implementation>
7
<Performer>Kassierer</Performer>
8
</Activity>
9
<Transitions>...</Transitions>
10
11
...
<WorkflowProcess>
3 Abgrenzung bestehender Ausführungssprachen
3.2.6
40
Applikation
Mit einer Applikation werden Anwendungen und Tools deklariert, die im Verlauf eines
Prozesses aufgerufen werden. Dadurch wird Abstraktion konkreter Implementierungen
oder Plattformen erreicht. Die Aufgabe der Prozess-Engine ist es, die in diesem Bereich
definierten Anwendungen zu instantiieren.
3.3
Zusammenfassung
BPEL unterstützt wie keine andere Sprache die Transaktionen, Kompensation, Fehlerbehandlung sowie abstrakte Prozesse und ist als Standard anerkannt. Obwohl der Umfang
der von BPEL unterstützten Elemente groß ist, bestehen auch Nachteile in BPEL und
zwar sind es fehlende Unterstützung von HumanTask, fehlende Metamodell und wechselseitige Abbildung zwischen BPEL und BPMN sowie Komplexität. Diese Vor- und Nachteile von BPEL werden von BPEL4People als Erweiterung zu BPEL übernommen. Durch
die Entwicklung und Einbettung der Spezifikation von WS-HumanTask wurde auch die
Komplexität deutlich erhöht.
Die menschlichen Interaktionen gehören zu den Kernelementen von XPDL und es werden dafür keine zusätzlichen Erweiterungen benötigt. Für die Einbindung von HumanTask kann ein Task verwendet werden, welcher im allgemeinen Fall mit dem Element
<taskUser> und für Aufgaben außerhalb des Workflows mit dem Element <taskManual>
versehen wird. In diesem Task sind Verweise auf ausführende Instanzen enthalten, in den
Aktivitäten können auch weitere beschreibende Attribute festgesetzt werden.
Die fehlende Unterstützung der oben genannten Konzepte von Transaktionen und Fehlerbehandlung in XPDL bringt Nachteile in der Praxis mit sich. Außerdem ist ein graphenbasierter Ansatz anfällig, unübersichtlich zu werden. Im Vergleich zum blockstrukturierten
Ansatz von BPEL erweist er sich aber als flexibler.
Zu den weiteren Vorteilen von XPDL gehören die integrierte Unterstützung menschlicher
Interaktionen über die Webservices und die Definition der ausführenden Instanzen und
Teilnehmer. Durch die vordefinierten Standardeingaben ist es in XPDL auch möglich,
Prozesse zu simulieren, was bei größeren Prozessen gute Anwendung zum Testen der
Arbeitsabläufe findet.
Abschließend bietet sich somit die Festlegung, dass die beiden Sprachen verschiedene
Zielsetzungen haben: BPEL mit BPEL4People werden als Prozessausführungssprachen im
Umfeld der Webservices verwendet und XPDL dient als Austauschformat für verschiedene
BPMN-Anwendungen. Bei der Wahl, welche der beiden Sprachen in einem Projekt zu
3 Abgrenzung bestehender Ausführungssprachen
41
benutzen ist, muss deswegen die Zielsetzung des Projekts in Betracht gezogen werden.
Jede dieser Sprachen hat ihre überzeugenden Aspekte und die beiden Sprachen befinden
sich noch in Entwicklung.
Kapitel 4
Rich Internet Application
Technologien
Rich Internet Applikationen (RIA), die in der letzten Zeit immer mehr Verbreitung finden,
sind Web-Anwendungen, die im Gegensatz zu den traditionellen auf HTML basierten Webapplikationen reichere Funktionalität und Interfaces besitzen, welche mit den DesktopAnwendungen vergleichbar sein können. Sie werden von den Web-Browsern nicht direkt
unterstützt, erfordern aber keine lokale Installation.
Die Forderung von den Internetapplikationen nach Benutzerschnittstellen, wie man sie
eigentlich nur noch von reinen Desktop-Applikationen kennt, entstand durch die Entwicklung von serviceorientierten Architekturen, für welche die RIA ein bequemes Front-end
anbieten.
Sie können in vielen Bereichen zum Einsatz kommen und mit dem World Wide Web
als globale Informationsplattform auch als Basis von Unternehmensapplikationen benutzt
werden. Gegenüber den zuvor entwickelten Client-Server-Webtechnologien bieten die RIA
erhebliche Vorteile für Geschäftsanwendungen im Unternehmensumfeld. Sie verbessern
und erweitern den Anwendungsbereich von Webapplikationen in Unternehmen, globale Geschäftsprozesse lassen sich einfacher automatisieren und ein zentrales Management
von Informationsdiensten, welches durch diese Technologie möglich wird, bringt weitere
betriebliche Vorteile mit sich.
Traditionelle Webapplikationen wurden in der Client-Server-Architektur erstellt, wo die
gesamte Anwendung auf dem Server implementiert ist und auf dem Client nur die Präsentation der Inhalte stattfindet. Bei den RIAs werden auch die Client-Ressourcen ausgenutzt, indem eine größere Verteilung der Daten am Client anfällt, der nun auch einen
größeren Teil der Programmlogik übernimmt.
4 Rich Internet Application Technologien
43
Da die Verarbeitung der Daten und die Berechnungen teilweise lokal erfolgen, vermeidet
die RIA-Technologie unnötige Last auf dem Netzwerk durch spezielle Techniken wie z.B.
das Vorladen oder partielles Laden von Daten, die gecacht werden, bis der Nutzer sie
benötigt. Dies reduziert die Notwendigkeit von Serveranfragen zur Laufzeit und erhöht
die Leistungsfähigkeit und Performance der Applikationen. RIAs lassen sich viel flüssiger bedienen, sie reagieren schneller auf die Eingaben der Benutzer und Rückmeldungen
können schneller erzeugt werden.
Manche RIA können auch im Offline-Modus ausgeführt werden und müssen nicht unbedingt zu jedem Zeitpunkt mit dem Webserver verbunden sein. Die Nachfrage nach
Offline-Funktionen hat einige RIA-Hersteller dazu bewogen, zum alten “fat client” zurückzukehren und Möglichkeiten zu schaffen, Webapplikationen auf dem Desktop auszuführen.
Adobe AIR und Google Gears sind Beispiele fur diesen Trend.
Ein gemeinsames Merkmal dieser Desktop-RIAs ist die Plattformunabhängigkeit. Das
Betriebssystem an sich spielt keine Rolle mehr. Die RIA-Plattform regelt den Zugang zu
Ressourcen wie dem lokalen Dateisystem oder der Datenbank.
Die Möglichkeit der Einbindung von multimedialen Daten ist ein weiteres wichtiges RIAFunktionsmerkmal. Interaktionsmöglichkeiten werden zum Beispiel durch die Bedienbarkeit über Tastenkürzel oder Drag-and-Drop-Möglichkeiten erweitert.
4.1
Vergleich bestehender Rich Internet Application
Technologien
Die Architektur der Rich Internet Applikationen unterscheidet sich und reicht von den
“Rich Fat Clients” bis zu den “Rich Thin Clients” (Abbildung 4.1). Die Architektur
einer “Rich Thin Client”-Applikation ist ähnlich einer klassischen HTML-basierten Webapplikation. Auch hier ist die gesamte Applikation serverseitig implementiert, statt des
Browsers wird jedoch eine mächtigere User Interface Rendering Engine benötigt, die entweder separat auf dem Client oder aber als Plugin eines Internetbrowsers zu installieren
ist. Die weiteren Architekturvarianten unterscheiden sich von der “Rich Thin Client”Variante dadurch, dass mehr und mehr Logik vom Server auf den Client ausgelagert wird.
Eine Möglichkeit dieser Auslagerung besteht darin, die Präsentationslogik auf dem Client
auszuführen, die Geschäftslogik jedoch noch auf dem Server zu lassen. Im extremsten Fall
- der “Rich Fat Client”-Variante - liegt die gesamte Applikationslogik auf dem Client vor
und lediglich die Daten werden noch auf einem Server gehalten.
Vor dem Einsatz von RIA-Technologie muss jedoch die Entscheidung darüber getroffen
4 Rich Internet Application Technologien
44
Bild 4.1: RIA-Architektur vgl. [Wal08]
werden, welche Applikationen überhaupt mit derartiger Technologie entwickelt oder erweitert werden sollen und welche Technologie aus dem heute noch unübersichtlichen Markt
verwendet werden soll. Die Entscheidung, ob für die Entwicklung einer Webapplikation
(oder deren Teile) RIA-Technologie eingesetzt werden soll, hängt von den Anforderungen
an die Benutzerschnittstelle ab. Dabei steigen der Entwicklungsaufwand und die Belastung
des Netzwerks im Betrieb überproportional zu den Anforderungen an die Benutzerschnittstelle, die in der Webapplikation realisiert werden soll.
Bild 4.2: Einsatzbereich für RIA-Technologie vgl. [Wal08]
4 Rich Internet Application Technologien
45
Die Technologien zur Umsetzung der Rich Internet Applikationen sind typischerweise
Ajax-Lösungen, die auf JavaScript basieren oder Lösungen, die auf Adobes “Flash” Umgebung basieren. Für den Einsatz von Flash gibt es mittlerweile mehrere Vorgehensweisen. Flash-Applikationen können wie üblich über die Tools, wie Adobe Flash oder
SWiSH, erstellt werden. Es ist auch möglich, die Applikation in einer XML-Sprache zu
programmieren und durch einen Flash-Compiler in eine ausführbare SWF-Datei umzuwandeln. Diesen Ansatz verfolgen sowohl Adobe Flex als auch OpenLaszlo. Ajax selbst
ist keine eigenständige Technologie, sondern eine Konzeption der Benutzung mehrerer
angrenzenden Technologien. In folgenden Unterabschnitten werden Ajax und Adobe Flex
vorgestellt und ihre Anwendung in Web-Applikationen behandelt.
4.1.1
AJAX
Ajax (Asynchronous JavaScript and XML) ist eine Gruppe zusammenhängender Techniken für die Entwicklung von Web-Schnittstellen, die auf der Clientseite als interaktive
Anwendungen benutzt werden und es erlauben, Anfragen an den Server durchzuführen
und die Webseiten zu verändern, ohne dass die Webseite komplett neu geladen wird.
Mithilfe von Ajax rufen die Web-Applikationen die Daten vom Server asynchron im Hintergrund ab und beeinflussen die Darstellung und das Verhalten der Seiten nicht.
Ajax ist eine Sammlung von Technologien, die seit der Entstehung von Web existieren
und eine Ajax-Anwendung basiert auf folgenden Web-Techniken:
• Eine Kombination von HTML (oder XHTML) und CSS zur Darstellung und Gestaltung der Information
• Document Object Model (DOM) zur dynamischen und interaktiven Repräsentation
der Daten oder Inhalte
• Datenaustausch und -transformation unter Einsatz von XML und XSLT
• XMLHttpRequest-Objekt für asynchrone Extraktion der Daten von dem Server
• JavaScript, welches als Schnittstelle zwischen einzelnen Komponenten dient
Die Ajax-Anwendungen basieren auf dem Client-Server-Architekturprinzip, so dass sowohl
im Browser als auch auf dem Server eine Komponente notwendig ist, die eine Ajax-basierte
Kommunikation ermöglicht.
Im Browser wird zur Umsetzung solcher Komponente meistens eine umfangreiche Funktionalität benötigt, die auf JavaScript und XMLHttpRequest-Objekt beruht und für welche
zwei mögliche Varianten der Umsetzung zur Verfügung stehen:
4 Rich Internet Application Technologien
46
Direkte Ajax-Implementierung Dabei ist auf der Clientseite ein API zur direkten
Kommunikation von Daten verfügbar. Dafür muss auf der Serverseite ein Einstiegspunkt
zur Übermittlung der Daten realisiert werden.
Indirekte Ajax-Implementierung Bei dieser Vorgehensweise werden von der Serverseite an die Clientseite neue HTML-Fragmente gesendet und die vorhandene Seite wird
ergänzt oder Teile davon werden ersetzt. Dafür wird auf der Serverseite die anzuzeigende Seite komplett neu aufgebaut, es werden jedoch nur die relevanten Differenzen zur
Clientseite übertragen.
Beide Verfahren haben ihre Vor- und Nachteile. Während die direkte Verwendung oft
serverseitige Ressourcen schont, vereinfacht die indirekte Variante die Implementierung.
Der Prozessfluss der Anwendung und die eigentliche Programmlogik werden auf einem
Server untergebracht. Das kann in Form von EJBs, .NET-Komponenten oder aber in Form
von Skript-Komponenten sein. Eine spezifische Technik, mit deren Hilfe die serverseitige
Programmlogik umgesetzt werden muss, wird vom Ajax-Konzept nicht erfordert. Sowohl
der Server als auch die Anwendungslogik werden im Ajax-Kontext als Server-Plattform
bezeichnet.
Zur Aufgabe des Webservers gehört bei den Ajax-Applikationen unter anderem die Bereitstellung der im Browser benötigten Komponenten. Da aber ein Cross-Site-Scripting
aufgrund der Sicherheitseinstellungen der Browser nicht erlaubt ist, stellt der Server auch
Daten von anderen Servern für die Clientseite zur Verfügung und übernimmt damit die
Funktion eines Proxy-Rechners.
Ajax ist eine einfache Technologie, die von den meisten Browsern unterstützt wird. Die
einzige vorläufige Bedingung für den Einsatz von Ajax ist die Verwendung von JavaScript,
wodurch alle in Ajax vorhandenen Techniken zusammen verbunden werden. JavaScript ist
eine schlanke, dynamisch typisierte, objektorientierte, aber klassenlose Skriptsprache, die
dennoch allen objektorientierten Programmierparadigmen unter anderem auf der Basis
von Prototypen gerecht wird. In JavaScript lässt sich objektorientiert und sowohl prozedural als auch rein funktional programmieren.
4.1.2
Adobe Flex
Bei Flex (Referenz auf die Flexseite) handelt es sich um ein Open-Source-Framework
für die Entwicklung und Pflege webbasierter Anwendungen, welche sich in allen gängigen
Browsern ausführen lassen. Allerdings wird hierfur als Vorraussetzung eine Vorinstallation
des Flash-Plugins in der Version 9 benötigt. In der Praxis stellt es kein Hindernis dar,
4 Rich Internet Application Technologien
47
da das Flash-Plugin laut Adobe bereits auf über 98%1 aller Desktops weltweit installiert
ist. Für die Entwicklung der Flex- Anwendungen kann sowohl eine kostenloses Flex-SDK
R Flex
R BuilderTM
(Software Development Kit) als auch ein kostenpflichtiger Adobe
verwendet werden.
Das Flex-Framework schliesst in sich einen Kernsatz von Sprachen und Bibliotheken ein,
die als Grundlage aller Flexanwendungen dienen. Durch die Benutzung von MXML, ActionScript und der Klassenbibliothek von Flex kann der Inhalt der Anwendung konstruiert,
kompiliert und in einen Flash-Player geladen werden.
MXML
MXML ist eine XML-basierte Auszeichnungssprache ursprünglich entwickelt für Beschreibung des Bildschirmlayouts. In dieser Hinsicht ähnelt sie sich HTML. Mit den MXMLTags können Komponenten für Formensteuerung und Mediawiedergabe den Layoutcontainern wie Grid zugefügt werden. Zusätzlich können mithilfe von MXML Effekte, Transitionen, Datenmodelle und Datenbindung beschrieben werden. MXML ist hinreichend
robust, so dass es möglich ist, viele Applikationen vollständig mit MXML zu bilden.
Obwohl MXML den Flex-Inhalt deklarativ erzeugt, ist sie recht leistungsstark. MXML
bietet eine schnelle und mächtige Art, das Layout und den Inhalt der Benutzerschnittstellen zu erzeugen. Die MXML-Dokumente werden jedoch in mehreren Schritten kompiliert.
Der erste davon konvertiert MXML in eine Klasse von ActionScript. Das bedeutet, dass
die MXML-Dokumente die volle Kraft des objekt-orientierten Designs enthalten, bieten
aber den Komfort einer Auszeichnungssprache. Außerdem werden die MXML-Dokumente
als Klassen von ActionScript zur Laufzeit behandelt.
ActionScript
ActionScript ist die Programmiersprache, die vom Flash-Player verstanden wird und ist
die grundlegende Engine für alle Flex-Anwendungen. MXML vereinfacht die Gestaltung
des Bildschirms und viele Grundaufgaben, doch alles, was mit MXML möglich ist, ist
auch mit ActionScript möglich und mit ActionScript kann mehr gemacht werden als mit
MXML. Zum Beispiel ist ActionScript erforderlich, um auf Ereignisse wie Mausklicks zu
reagieren.
Obwohl es möglich ist, eine Applikation vollständig mit MXML oder mit ActionScript zu
bilden, ist es mehr üblich und sinnvoll, MXML und ActionScript in einer geeigneten Ba1
Quelle: http://www.adobe.com/products/player census/flashplayer/version penetration.html
4 Rich Internet Application Technologien
48
lance zu benutzen. Beide haben ihre Vorteile und sie funktionieren gut zusammen. MXML
ist am besten für die Gestaltung der Benutzeroberfläche und elementare Datenfunktionen
geeignet, ActionScript für Benutzerinteraktion, komplexe Datenfunktionalität und jede
spezifische Funktionalität, die in der Klassenbibliothek von Flex nicht enthalten ist.
ActionScript ist nativ vom Flash Player unterstützt und erfordert keine zusätzlichen Bibliotheken, um zu laufen. Alle nativen Klassen von ActionScript (Klassen, die im Flash
Player eingebaut sind) sind im Paket flash oder im Top-Level-Packet gepackt. Im Gegensatz ist Flex-Framework in ActionScript geschrieben, dessen Klassen aber werden in einer
.swf-Datei zur Kompilierungszeit eingefügt. Alle Klassen von Flex-Framework befinden
sich im mx-Packet.
Unterschiede zwischen traditionellen und Flex-Webanwendungen
Viele Anwendungen im Web benutzen HTML als ihre Benutzerschnittstelle. FlexAnwendungen sind in vielen Hinsichten ähnlich, haben aber deutliche Unterschiede. Sowohl traditionelle als auch Flex-Anwendungen haben n Schichten. Die genaue Anzahl
und Typen der Schichten in einer Anwendung hängen von mehreren Faktoren ab. Die
meisten traditionellen Anwendungen haben zumindest eine Datenschicht, eine Funktionsschicht und eine Präsentationsschicht. Flex-Anwendungen haben eine Datenschicht und eine Funktionsschicht, allerdings führen sie auch eine Clientschicht ein, was sie stark von den
traditionellen Webanwendungen unterscheidet. Die Clientschicht der Flex-Anwendungen
ermöglicht die Offlineberechnungen von den Clienten, das Freisetzen der Netzwerklatenz
und das Erstellen von reaktionsfähigen und höchst interaktiven Benutzerschnittstellen.
Datenschichten bestehen hauptsächlich aus Datenbanken oder ähnlichen Resourcen. Die
Funktionsschichten bestehen aus der Kernlogik der Anwendungsfunktion. Zum Beispiel
kann eine Funktionsschicht Aufforderungen von einer Client- oder Präsentationsschicht
annehmen, die Datenschicht anfragen und die angefragten Daten zurückgeben.
In traditionellen Anwendungen besteht die Präsentationsschicht aus HTML, CSS, JavaScript, JSP, ASP, PHP oder ähnlichen Dokumenten. Üblicherweise wird eine Aufforderung
vom Webbrowser des Benutzers zu einer spezifischen Resource der Präsentationsschicht
gemacht und der Webserver startet die erforderlichen Interpreter, um die Resource in
HTML und JavaScript zu konvertieren, welche danach dem Webbrowser auf dem Clientcomputer zurückgegeben wird. Technisch gesehen ist der im Browser übersetzte HTML
eine Clientschicht in einer traditionellen Webanwendung. Da aber die Clientschicht einer
traditionellen Webanwendung zustandslos und nicht reagierend ist, wird sie im Allgemeinen nicht als vollwertige Schicht betrachtet. (Eine Ausnahme dafür ist der Fall einer
Ajax-Anwendung, welche JavaScript und XML auf der Clientseite benutzt um reagierende
4 Rich Internet Application Technologien
49
und anspruchsvolle Clientschichten zu bilden.)
Die Flex-Anwendungen sind gewöhnlich innerhalb der Präsentationsschicht eingebettet.
Zusätzlich können sie mit der Präsentationsschicht zusammengefügt sein, um fest gekopellte clientseitige Systeme zu bilden. Flex-Anwendungen benutzen Flash Player, um
anspruchsvolle Teile der Clientschicht der Anwendung auszuführen. Ein Client der FlexAnwendung ist zustandsbasiert, was bedeutet, dass er die Darstellung ändern kann, ohne
eine Aufforderung an den Server senden zu müssen. Außerdem ist der Client der FlexAnwendung reaktionsfähig. Zum Beispiel kann der Flash Player auf die Benutzerinteraktionen wie Mausbewegungen, Mausclicks und Tastatureingaben und auf Ereignisse wie
Notifikationen von der Funktionsschicht, wenn Daten an den Client geliefert werden, reagieren. Flash Player kann auch auf die Timerereignisse reagieren. Da der Flash Player
ein intelligenter Client ist, ist er fähig, den Netzwerk-Overhead zu vermeiden und die
Bandbreitenutzung zu sparen, indem er die clientseitige Logik steuert, ohne die Funktionsschicht hinzuzuziehen. Zum Beispiel kann eine Flex-Anwendung den Benutzer durch
eine schrittbasierte oder Assistent-ähnliche Interface führen, die Daten sammeln und validieren und es dem Benutzer erlauben, die vorhergehenden Schritte zu aktualisieren und
editieren, ohne die Funktionsschicht aufzufordern, bis der Benutzer entscheidet, die Daten
abzusenden.
4.2
Fazit
Das grundsätzliche Problem, auf das bei fast allen Lösungen gestoßen wird, ist die Unreife der Produkte und die hohe Fragmentierung des Marktes. Das erschwert eine Auswahl,
wenn eine langfristige Investition geplant wird. In dieser Situation ist es sinnvoll, bei der
Auswahl einer Lösung ausschließlich von den konkreten Anforderungen und Randbedingungen der zu entwickelnden Applikation auszugehen.
Ein weiterer Punkt ist es, dass für die RIA entsprechende Plug-ins, Laufzeitumgebungen
oder Skripting Engines installiert werden müssen. Diese werden im Laufe der Zeit aktualisiert, so dass die lokale Version und die Applikationen auf dem Laufenden gehalten
werden müssen.
Für die Implementierung des Prototyps im praktischen Teil dieser Arbeit wurde eine Entscheidung zugunsten der Adobe Flex Technologie getroffen. Diese Technologie zeichnet
sich im Gegensatz zu Ajax dadurch aus, dass sie von allen Browsern unterstützt wird
und die damit erstellten Applikationen in jedem Browser identisch aussehen und funktionieren. Die gemeinsame balancierte Verwendung von MXML und ActionScript liefert ein
mächtiges Konzept für die Umsetzung der Rich Internet Applikationen.
Kapitel 5
Kontept/Architektur des Business
Process Modeler
Das Ziel ist es, ein Werkzeug zur Modellierung von Arbeitsabläufen und Geschäftsprozessen zu entwickeln. Hierbei sollte es sich um eine Lösung handeln, welche die BPMN
unterstützt, möglichst benutzerfreundlich und im Rahmen einer SaaS-Lösung innerhalb
eines Browsers ausführbar ist. Für die Entwicklung und Umsetzung der Softwaresysteme wird gewöhnlich eine durch das klassische Wasserfallmodell definierte Vorgehensweise
verwendet. Im Folgenden werden die ersten zwei Phasen des Wasserfallmodels vorgestellt:
1. die Definition der Anforderungen
2. Entwurf und Design des Systems
Anschließend wird ein Beispiel der Vorgehensweise eines Anwenders bei der Verwendung
des Softwaresystems beschrieben.
5.1
Anforderungen
In dieser Phase des Wasserfallmodells werden alle Leistungen beschrieben, die die zu erstellende Software erbringen soll. Bestandteile dieser Phase, auf die in diesem Abschnitt
eingegangen wird, sind: funktionale Anforderungen, nichtfunktionale Anforderungen und
Anwendungsfälle (Use Cases). Die funktionalen Anforderungen beschreiben, was die Software in bestimmten Situationen bzw. bei bestimmten Eingaben leisten soll. Die nichtfunktionalen Anforderungen sind Anforderungen, die über die Funktionalität der Software hinausgehen (wie zum Beispiel Ressourcenverbrauch, Wahl der Entwicklungsumge-
5 Kontept/Architektur des Business Process Modeler
51
bung usw.). Die Use Cases beschreiben funktionale Anforderungen im Hinblick auf die
Benutzerziele.
Funktionale Anforderungen
Folgende funktionale Anforderungen wurden für die Umsetzung des Modellierungswerkzeugs vorgegeben:
- Software muss mittels eines URL-Aufrufes innerhalb eines Browsers ausführbar sein.
- Ein Zugriff auf die BPMN-Elemente soll mittels einer Schnellzugriffsleiste bzw. eines
Akkordeon-Elements ermöglicht werden.
- Mittels des Drag&Drop-Verfahrens soll es möglich sein, die Elemente der BPMNNotation auf der Benutzeroberfläche zu platzieren und zu verschieben.
- Es soll möglich sein, Elemente gemaß der BPMN-Notation untereinander zu verbinden.
- Mittels eines Menüaufrufes soll es ermöglicht werden, eine Dialogbox mit allgemeinen
Einstellungen aufzurufen.
- Mittels eines Doppelclicks auf ein Aktivitäten-Element soll ermöglicht werden, eine Dialogbox mit Einstellungen für das ausgewählte Element aufzurufen.
- Mittels eines Doppelclicks auf ein Verbindungselement (Sequence Flow) soll es
ermöglicht werden, eine Dialogbox mit Einstellungen für das ausgewählte Element aufzurufen.
- Es sollen für die Benutzeroberflache übliche Funktionalitäten (ausschneiden, kopieren,
einfügen) umgesetzt werden.
- Es soll ermöglicht werden, im PAVONE ProcessModeler XML-Format gespeicherte Prozessdefinitionen zu importieren.
- Es soll ermöglicht werden, Prozessdefinitionen im PAVONE ProcessModeler XMLFormat zu exportieren.
Nichtfunktionale Anforderungen
Einer Anwendung, die innerhalb eines Browsers ausgeführt wird, stehen zwangsläufig geringere Ressourcen zur Verfügung als einer Anwendung, die direkt auf die Systemressourcen zugreifen kann, weil zum einen der Zugriff über mehrere Schichten erfolgen
5 Kontept/Architektur des Business Process Modeler
52
muss und zum anderen ein Zugriff auf die Hardwarebeschleunigungsschnittstellen (solche
wie z.B. DirectX-Schnittstellen unter Windows) versperrt ist. Somit stehen einer FlashAnwendung nur die CPU-Ressourcen zur Verfügung, auf die die Anwendung über mehrere
“Umwege” (Schichten) (Browser ⇒ System) zugreifen kann. Dies führt trivialerweise auf
die nichtfunktionale Anforderung, dass die Software möglichst effizient programmiert werden muss.
Use Cases
Es können folgende USE CASES modelliert werden:
UC1: Neuen Arbeitsablauf modellieren
Hauptakteur: Kunde1, Kunde2
Nebenakteure: keine
Hauptszenario:
1. Kunde startet eine neue Modellierungssession
2. Kunde setzt mittels der Dialogbox Allgemeine Einstellungen
3. Kunde modelliert einen Arbeitsablauf
4. Kunde setzt mittels der Dialogboxen Einstellungen für Aktivitäten und Flüsse
5. Kunde speichert den modellierten Arbeitsablauf
UC2: PAVONE ProcessModeler XML-Definition editieren
1. Kunde1 öffnet die im PAVONE ProcessModeler XML-Format definierte Arbeitsabläufe
2. Kunde1 bearbeitet den Arbeitsablauf im PAVONE ProcessModeler
3. Kunde1 speichert die neue Version des Arbeitsablaufs im PAVONE ProcessModeler
im XML-Format
4. Kunde2 öffnet die XML-Datei mit dem Arbeitsablauf und bearbeitet diesen
5.2
Design und Entwurf
Im Wasserfallmodel bestehen das Design und die Entwurf-Phase aus zwei Teilen: dem Grobentwurf und dem Feinentwurf. Im Grobentwurf wird das System in Teilsysteme/Module
5 Kontept/Architektur des Business Process Modeler
53
zerlegt, die für die Umsetzung erforderlichen Bibliotheken, Frameworks und Module werden ausgewählt.
5.2.1
Grobentwurf
In dem Abschnitt zuvor wurde die Anforderung definiert, dass der Benutzer in der Lage
sein soll, eine PAVONE ProcessModeler XML Ausführungsdatei in den Prototyp zu laden, im Prototyp zu bearbeiten und die Änderungen als eine PAVONE ProcessModeler
XML Ausführungsdatei zu speichern. Diese Anforderung gibt die Richtung der Entwicklung des Prototyps vor. Dieser muss im Prototyp über eine Schnittstelle verfügen, welche
die XML-Dateien laden, interpretieren und speichern kann. Da der direkte Dateizugriff
wegen der Sicherheitsrestriktionen des Adobe Flash Players nicht möglich ist, muss dies
unter Einbeziehung eines Webservers geschehen. Hierfür muss eine Vermittlungsschnittstelle umgesetzt werden, welche eine Kommunikation zwischen dem Webserver und dem
Prototyp ermöglicht. Dies führt nun auf die im Folgenden beschriebene Softwarearchitektur.
XML
Prototyp
XML
JBoss Webserver
Desktop
XML
PAVONE ProcessModeler
Bild 5.1: Systemarchitektur: Externe Anforderungen
Allgemein wird für ein Softwaresystem eine zentrale Instanz gebraucht, welche die Arbeit einzelner Module untereinander koordiniert. (Im weiteren Verlauf wird dieses Mo-
5 Kontept/Architektur des Business Process Modeler
54
dul als Kernel bezeichnet.) Da es sich bei der Software um ein bedienbares Softwarewerkzeug handelt, wird entsprechend ein Benutzeroberflächenmodul benötigt, welches die
Darstellungs- und Bedingungslogik der gesamten Anwendung umsetzt. (Im Weiteren wird
es als Benutzeroberflächenmodul bezeichnet.) Bei dem Softwaresystem handelt es sich um
ein Werkzeug, welches eine Modellierung von Arbeitsabläufen mittels der BPMN-Notation
unterstützen muss. Aus diesem Grund wird eine Datenstruktur benötigt, welche die einzelnen Elemente und deren Beziehungen im System speichert und Zugriffsmöglichkeiten für
die anderen Module anbietet. (Im folgenden wird dieses Modul als BPMN Datenstruktur
bezeichnet.)
Da das Modellierungswerkzeug auf die als XML-Dateien gespeicherten Arbeitsabläufe
zugreifen und die Arbeitsabläufe speichern muss, wird ein Schnittstellenmodul benötigt,
welches einerseits die in den Dateien gespeicherten Einstellungen und Modeler-Strukturen
auf die interne Darstellung abbildet und andererseits die im internen Format gespeicherten
Informationen in einer für die anderen Anwendungen verstandlichen Form speichert (im
Folgenden als XML-Zugriffsmodul bezeichnet).
Für die Zusammenarbeit der einzelnen Module müssen geeignete Kommunikationsschnittstellen entwickelt werden, wobei die komplette Kommunikation über das Kernelmodul
zentral erfolgen soll, da es im allgemeinen von Vorteil ist, eine einzige koordinierende Instanz zu haben, welche einen einheitlichen Zugriff auf das gesamte System ermöglicht und
regelt.
Ein Überblick der Gesamtarchitektur ist in der Abbildung 5.2 zu sehen:
Benutzeroberfläche
Modul
Kernel
Modul
XML Dateizugriff
Modul
Bild 5.2: Überblick der Softwarearchitektur
BPMN Datenstruktur
Modul
5 Kontept/Architektur des Business Process Modeler
55
Auswahl der Bibliotheken
Da es sich bei diesem Softwaresystem um eine Anwendung handelt, die mit Grafiken
arbeitet, werden die Klassen zum Laden von Bitmap-Grafiken, sowie die mathematischen
Funktionalitäten für die Abbildung der geladenen Bitmaps auf die Benutzeroberfläche
benötigt. Diese Funktionalitäten werden von Standard Flash Bibliotheken geliefert.
• flash.display.Graphics;
• flash.geom.Matrix;
• flash.display.BitmapData;
• flash.display.Bitmap;
Bei den auf Benutzeroberflächen basierten Softwaresystemen werden sehr viele Abläufe
über die Ereignisse (Aktivieren eines Menüs, Mausdoppelklick, etc) ausgelöst und abgehandelt. Hierfür können die Flash-Klassen verwendet werden:
• flash.display.StageDisplayState;
• flash.events.*;
• flash.ui.Mouse;
Bei den Dialogboxen, die umgesetzt werden müssen, handelt es sich technisch gesehen um
Pop-up Fenster. Für diese wird eine entsprechende Flash-Klasse benötigt:
• mx.managers.PopUpManager;
Um auf das lokale Dateisystem zuzugreifen, muss eine entsprechende Klasse verwendet
werden:
• flash.net.FileReference;
Zur Kommunikation mit dem Webserver werden Funktionalitäten zur Arbeit mit dem
Netzwerk benötigt:
• flash.net.*;
5 Kontept/Architektur des Business Process Modeler
5.2.2
56
Feinentwurf
Als Nächstes müssen die in dem Grobentwurf entstandenen Module verfeinert werden.
Dafür werden die Module in Teilmodule unterteilt und deren Funktionalitäten und Eigenschaften sind auf die Strukturen, die den einzelnen Programmblöcken entsprechen, abzubilden. ActionScript ist eine objekt-orientierte Sprache und viele Funktionalitäten und
Eigenschaften lassen sich dabei intuitiv direkt in den einzelnen Klassen umsetzen. Ferner ermöglicht eine objekt-orientierte Vorgehensweise auch bessere Erweiterbarkeit und
Wartbarkeit.
Verfeinerung des Benutzeroberflächenmoduls
Erfahrungsgemäß besteht die Benutzeroberfläche eines “klassischen” Modellierungswerkzeugs aus einer bedienbaren Menüleiste mit Standardaktionen, einer Schnellzugangsleiste mit am häufigsten verwendeten Aktionen, einem so genannten AkkordeonBedienungselement, welcher den Zugriff auf die sämtlichen Elemente einer Notation
ermöglicht, sowie dem eigentlichen Modellierungsbereich.
Zur Darstellung und Umsetzung der Modellierungsumgebung bietet sich ein CanvasObjekt der Entwicklungsumgebung an.
Bei der Abbildung der graphischen Inhalte auf das Canvas-Objekt sind grundsätzlich zwei
Vorgehensweisen möglich. Zum einen liefert Adobe Flex die graphischen Objekte des jeweiligen Darstellungstypes (wie zum Beispiel Texte, Texteingabefelder, Bitmaps usw.),
welche direkt erzeugt und dem Canvas-Objekt hinzugefügt werden können. Dies vereinfacht zwar die Programmierung, führt jedoch in der Praxis bei großeren Darstellungen zur
Verringerung der Performance. Eine andere Vorgehensweise besteht darin, die jeweiligen
graphischen Objekte in Form vom Bitmaps zu erzeugen und auf das Canvas-Objekt zu
plotten.
Eine nichtfunktionale Anforderung ist es, mit Ressourcen möglichst sparend umzugehen.
Aus diesem Grund muss die zweite aufwendigere aber schnellere Vorgehensweise gewählt
werden. Diese Vorgehensweise bietet sich auch für die Umsetzung der weiteren Elemente: dem Akkordeon und der Schnellzugangsleiste. Diese können im Endeffekt als Bitmaps
erzeugt und auf die Fläche geplottet werden. Dies würde in der Praxis einen wesentlich flexibleren Einsatz dieser Elemente ermöglichen, da es möglich wäre, diese auf eine beliebige
Art darzustellen und auf eine beliebige Stelle der Benutzeroberfläche zu platzieren.
Diese Elemente können gemaß dem folgenden Schema (in der Abbildung 5.3 zu sehen)
angeordnet werden:
5 Kontept/Architektur des Business Process Modeler
57
Menüleiste
Schnellzugangsleiste
Akkordeon
Medellierungsoberfläche
Bild 5.3: Benutzeroberfläche. Standardkomponenten.
Menüleiste
Die Umsetzung der Menüleiste ist durch die technischen Gegebenheiten der Entwicklungsumgebung vorgegeben und lässt keine Variationen bei dem Design und Implementierung
zu. Technisch gesehen handelt es sich um eine Mischung aus MXML und ActionScript. In
MXML wird der optische Menüaufbau und in ActionScript die eigentliche Funktionalität
der einzelnen Menüaufrufe umgesetzt.
1
<menuitem label="File">
2
<menuitem label="New" data="new"/>
3
...
4
</menuitem>
Schnellzugangsleiste
Bei der Schnellzugangsleiste handelt es sich um eine rechteckige Struktur mit einer Menge
von Symbolen. Durch einen Mausklick auf eines dieser Symbole muss ein diesem Symbol
zugeordnetes Ereignis ausgelöst und behandelt werden.
Bild 5.4: Schnellzugangsleiste
Somit wird eine Klasse benötigt, welche in den Objektvariablen die absoluten Koordinaten
der jeweiligen Elemente speichert, eine Methode zum Zeichnen des Elements, sowie eine
5 Kontept/Architektur des Business Process Modeler
58
Methode, die die Mauseingaben behandelt und den Namen des angeklickten Symbols
zurückliefert.
Akkordeon
Beim Akkordeonelement handelt es sich um ein spezifisches Objekt, welches eine größere Menge von graphischen Elementen beinhalten und darstellen kann. Diese Elemente
können nach bestimmten Kriterien zu kleineren Teilgruppen unter einem jeweiligen gemeinsamen Label zusammengefasst werden. Durch die Aktivierung dieses Labels werden
die dazugehörenden Elemente angezeigt, während die Elemente von anderen Labels versteckt werden.
Bild 5.5: Akkordeon
Für die Umsetzung dieses Elements kann eine geeignete eigenständige Klasse (UIAccordion) entworfen werden. Eine Instanz dieser Klasse benötigt Koordinaten für die Darstellung
auf der Zeichenfläche und Variablen zum Speichern des jeweiligen Objektzustandes.
Da es sich um ein graphisches Element handelt, muss eine Methode zum Zeichnen implementiert werden, welcher als Parameter die Hauptzeichenfläche übergeben wird. Das
Akkordeonelement muss auf die Mauseingaben reagieren und entweder die selektierten
Elemente zurückliefern oder den Zustand des Akkordeonelements umschalten. Hierfür
wird eine Methode benötigt, welche die Mauseingabekoordinaten überprüft und eine entsprechende Aktion ausführt.
Lasso
Beim Lasso handelt es sich um eine spezielle Benutzeroberflächenfunktionalität, die es
ermöglicht, eine Gruppe von Elementen zu selektieren und ggf. zu verschieben. Zur Aktivierung dieser Funktionalität muss die Benutzeroberfläche des Softwaresystems mittels
einer Mauseingabefolge “umgeschaltet” werden. Für die “Schaltung” der Benutzeroberfläche ist das Kernel-Modul verantwortlich, deswegen muss diese Funktionalität in enger
5 Kontept/Architektur des Business Process Modeler
59
Bild 5.6: Uiaccordeon
“Zusammenarbeit” mit dem Kernel-Modul umgesetzt werden. Da es sich um eine abgegrenzte in sich geschlossene Funktionalität handelt, kann hierfür eine eigenständige Klasse
entworfen und eingesetzt werden.
Bild 5.7: Lasso im Einsatz
Ein Lasso wird auf bestimmte Koordinaten der Benutzeroberfläche “geworfen”. Diese
Stelle muss in dem Lasso-Objekt mittels einer hierfür geeigneten Methode (throwLassoAtCoords) gespeichert werden. Nachdem das Lasso-Objekt “geworfen” wurde, wird es
gezogen und alle Objekte, die in das Lasso geraten, werden markiert. Dieser Vorgang kann
in einer entsprechenden Methode (pullLassoToCoords()) umgesetzt werden. Diese Methode muss das Lasso optisch auf die angegebenen Koordinaten verschieben und mittels einer
Kollisionsabfrage die Elemente, die in das Lasso “geraten”, markieren. Falls graphische
Elemente mit dem Lasso markiert wurden, entsteht ein spezieller Bereich auf der Benutzeroberfläche, welcher die markierten Elemente und das Lasso im losgelassenen Zustand
enthält. Sobald nun der Mauszeiger über diesem Bereich schwebt, muss er sein Aussehen verändern, um zu verdeutlichen, dass dieser Bereich mit den selektierten Elementen
verschoben werden kann. Aus diesem Grund wird eine Methode (processMouseInput())
benötigt, welche das Aussehen des Mauszeigers entsprechend ändert. Falls der Benutzer
sich dazu entschließt, das Lasso und die im Lasso enthaltenen Elemente zu verschieben,
müssen die Lassokoordinaten und die Koordinaten der selektierten Elemente entsprechend
den neuen, bei der Bewegung entstehenden Koordinaten angepasst werden. Dies kann innerhalb einer Methode (moveCapturedElements()) umgesetzt werden. Für das Objekt der
5 Kontept/Architektur des Business Process Modeler
60
Klasse werden im Wesentlichen Variablen für den Start- und Endpunktkoordinaten des
Lassos benötigt.
Bild 5.8: Lasso-Klasse
Dialogboxen
Für die Anwendung werden insgesamt drei Dialoge benötigt. Ein Dialog, in welchem
die allgemeinen Einstellungen der aktuellen Sitzung manipuliert und angesehen werden
können, sowie zwei Dialoge, jeweils für erweiterte Einstellungen der Aktivitäten und Verbindungen.
Technisch gesehen kann eine Dialogbox als ein Popup-Fenster aufgerufen werden.
Für die Umsetzung des Popup-Fensters kann eine Mischstruktur aus der MXMLAuszeichnungssprache und dem ActionScript verwendet werden, wobei die meisten statischen Elemente des Popup-Fensters im MXML und die dynamischen in ActionScript
programmiert werden.
Beim Design und Entwurf muss für diese Dialoge die Vorgabe erfüllt werden, äußerlich und
funktionell den Dialogen aus der PAVONE ProzessModeller Anwendung zu entsprechen.
Ein Dialog besteht aus einer Menge der Elementen: Texteingabefeldern, einer CheckBox,
einem Radio- sowie einem Popupbutton. Um dieses Element zu entwerfen, muss verstanden werden, wie eine solche Struktur in der Adobe Flex Entwicklungsumgebung zu einem
Dialog umgesetzt werden kann.
Die ersten drei Elemente sind statisch und können mit der MXML-Auszeichnungssprache
umgesetzt werden. Hierbei wird eine hierarchische Struktur in einem XML-ähnlichen
Speicherformat erstellt. Der Typ der Struktur wird mittels eines entsprechenden Wurzeltags eingeleitet. Da es sich hierbei um ein Fenster handelt, wird die Struktur mit einem
(<mx:TitleWindow>)-Tag eingeleitet. Technisch werden für diejenigen graphischen Elemente, die sich innerhalb anderer graphischen Elemente befinden, die ihnen entsprechende
5 Kontept/Architektur des Business Process Modeler
61
Tags innerhalb der Tags der umschliessenden XML-Elemente im Dokument gesetzt. Da
alle graphischen Elemente innerhalb des Fensters platziert werden, muss dies durch das
Hinzufügen entsprechender Tags umgesetzt werden. Wenn zum Beispiel zwei Textfelder in
dem Dialog hinzugefügt werden müssen, wird dies durch den Einsatz von dem in der Entwicklungsumgebung definierten <mx:TextInput>-Tag eingeleitet. Als Parameter müssen
innerhalb des Tags absolute Koordinaten des Texteingabefeldes, ein das Element eindeutig
identifizierender Id, sowie eine Textzuweisung definiert werden.
1
<mx:TitleWindow>
2
<mx:TextInput x="80" y="10" id="BPMNActivityName" text ="Name"/>
3
...
4
</mx:TitleWindow>
Auf solche Weise können weitere statische Elemente, wie zum Beispiel Radiobuttons,
Checkboxen oder Panels hinzugefügt werden. Etwas komplizierter gestaltet sich die Umsetzung von dynamischen Elementen (wie zum Beispiel eines Popupbuttons). Deren Programmierung muss gewöhnlich mit Zuhilfenahme des ActionScriptes erfolgen. Der Einsatz des Scriptes erfolgt innerhalb der MXML-Auszeichnungssprache durch Einleitung
eines <mx:Script>-Tags. Für das Verhalten und die Reaktionen des dynamischen Elements muss ein Ereignismodell definiert werden, welches auf die Elementeingaben reagiert, sowie die dem Kontext entsprechenden Aktionen ausführt. Um den Datenaustausch
zwischen dem ActionScript und MXML-Elementen zu gewährleisten, muss eine MXMLDatenstruktur definiert werden, welche die den IDs zugeordneten Datenwerte dem ActionScript zur Verfügung stellt:
strAcitvityName = modelBPMNActivity.BPMNActivityName;
1
2
<mx:Model id="modelBPMNActivity">
<BPMNActivity>
3
<BPMNActivityName>{BPMNActivityName.text}</BPMNActivityName>
4
...
5
6
</BPMNActivity>
</mx:Model>
Bei den drei Dialogboxen handelt es sich praktisch um Minianwendungen, die mittels der
vorgestellten Techniken umgesetzt werden können.
5 Kontept/Architektur des Business Process Modeler
62
Bild 5.9: Aktivitäten-Dialog
Umsetzung der BPMN Datenstruktur
Für die Umsetzung der BPMN-Datenstruktur bietet sich eine strikte objekt-orientierte
Vorgehensweise an, wobei die einzelnen BPMN-Elemente auf jeweils entsprechende
ActionScript-Klassen abgebildet werden. Ähnliche Funktionalitäten der BPMN-Elemente
können in den jeweiligen Elternklassen zusammengefasst und in den Kinderklassen können
die Funktionalitäten und Ausprägungen der einzelnen Elemente verfeinert werden. Es ergibt sich das im Folgenden beschriebene dreistufige Klassenmodell.
Klassenstufe 1 Allgemein wird eine Oberklasse benötigt, die die gesamten Einstellungen für alle Elemente der Unterklassen speichert und eine einheitliche Behandlung aller
BPMN Elemente ermöglicht. (Dies sind zum Beispiel absolute Koordinaten, allgemeine
Einstellungen wie z.B. Schriften, Farben, Linienstarke usw.).
Bild 5.10: BPMNElement Klasse
5 Kontept/Architektur des Business Process Modeler
63
Klassenstufe 2 In der BPMN Notation sind vier Grundkategorien der Darstellungselemente (Flußobjekte, Verbindungsobjekte, Verantwortlichkeitsbereich und Artefakte)
definiert. Diese Objektgruppen besitzen unterschiedliche funktionelle Ausprägungen. So
besteht beispielsweise die Gruppe der Verbindungselemente aus unterschiedlichen Pfeilelementausprägungen mit Start und Zielkoordinaten. Dagegen besteht die Gruppe der
Flussobjekte aus Elementen mit fester Breite und wird auf bestimmte X, Y- Koordinaten
auf der Zeichenfläche abgebildet. Somit können die für die jeweilige Gruppe charakteristischen Methoden und Variablen in den entsprechenden Klassen zusammengefasst werden
und diese Funktionalität den Unterklassen zur Verfügung stellen.
Bild 5.11: Elemente der Klassenstufe 2
Klassenstufe 3 Durch die Klassen der Stufen 1 und 2 zur Verfügung gestellte Funktionalitäten ermöglichen es, Klassen mit konkreter Ausprägung der einzelnen BPMNElemente zu entwickeln. Es handelt sich somit um die Klassen, die die jeweiligen individuellen Ausprägungen der einzelnen BPMN-Elemente enthalten und umsetzen.
Bild 5.12: Elemente der Klassenstufe 3
Methoden zur Behandlung der Mauskollisionsabfragen
Für alle graphischen Objekte, die auf die Benutzeroberfläche platziert werden, wird
eine Methode benötigt, welche feststellt, ob ein Objekt angeklickt wurde oder nicht.
Grundsätzlich muss hierfür festgestellt werden, ob die Eingabekoordinaten innerhalb des
dargestellten Objekts liegen. Bei der Umsetzung dieser Methode muss beachtet werden,
Klassenebene 1
5 Kontept/Architektur des Business Process Modeler
BPMN Element
- Element ID
- Eigenschaften
- ...
Klassenebene 2
Klassenebene 3
64
Connection
Flow
- startXY
- endXY
...
- XYCoord
- ...
...
...
Activity
SequenceF.
MessageF.
- draw()
- ...
- draw()
- ...
Activity
XOR
- draw()
- drawText()
- draw()
- ...
Bild 5.13: Klassenhierarchie der BPMN-Elemente.
5 Kontept/Architektur des Business Process Modeler
65
dass es sich um eine der am häufigsten ausgeführten Operationen der Benutzeroberfläche
handelt. Aus diesem Grund muss diese Operation möglichst effizient ausführbar sein.
Am effektivsten wird diese Operation auf einem Rechteck ausgeführt, da an dieser Stelle
vier logische Abgleiche mit dem Rechteckkoordinaten genügen, um festzustellen, ob sich
der Punkt innerhalb des Rechtecks befindet. Bei den anderen Figuren, wie zum Beispiel
einem Kreis oder einer Raute führt dieser Vorgang auf eine Reihe von kostenintensiven
Berechnungen. An dieser Stelle bietet sich folgende Näherung an: berechne ein Rechteck,
welches eine Figur umschließt (Kosten: einmalig zwei Additionsoperationen, da technologiebedingt die Weite und Breite der Figur bekannt ist) und führe eine Abgleichsoperation
auf dem umschließenden Rechteck durch.
Eine etwas komplizierte Vorgehensweise muss zur Kollisionsabfrage für die Pfeiloperationen durchgeführt werden. Um zu berechnen, ob ein Pfeilelement getroffen wurde, wird
eine kostenintensive Berechnung, die nach Möglichkeit vermieden werden sollte, durchgeführt. Deswegen wird zuerst (ähnlich wie in dem Algorithmus davor) das Pfeilelement
mit einem leicht vergrößerten Rechteck umgeben, auf diesem Rechteck die Kollisionsabfrage durchgeführt, und erst wenn die Kollisionsabfrage positiv ist, wird die wirkliche
Pfeilelementkollisionsabfrage durchgeführt.
XML Dateien Physischer Zugriff
Wie bereits erwähnt, muss das Softwaresystem in der Lage sein, auf die XML-Dateien
zuzugreifen. Jedoch lässt das Sicherheitsmodell von Flash-basierten Anwendungen keinen
direkten Lese- oder Schreibzugriff auf das lokale Dateisystem zu. An dieser Stelle muss ein
kleiner Umweg genommen werden. Flash-Technologie lässt einen Dateiupload auf einen
Webserver zu und es ist möglich, auf die auf einem Webserver gespeicherte Dateien lesend
zuzugreifen. Somit kann ein Lesezugriff auf eine lokal gespeicherte Datei als eine Operation
aus Dateiupload und URL Lesezugriff auf die hochgeladene Datei umgesetzt werden. Auf
ähnliche Weise kann der Speichervorgang einer Datei modelliert werden. Die XML-Datei
wird zuerst auf dem Webserever gespeichert und anschließend runtergeladen und auf dem
lokalen Dateisystem gespeichert.
Abbildung der XML-Dateien auf die Modeller interne Darstellung der Arbeitsabläufe
Nachdem eine XML Datei ausgelesen wurde, muss deren Inhalt auf die interne Einstellungen, Notationsobjekte und Verbindungen abgebildet werden. Hierzu muss zuerst der
Aufbau der PAVONE ProzessModeler XML-Datei analysiert werden und anschließend
5 Kontept/Architektur des Business Process Modeler
66
müssen Methoden zur Abbildung auf die interne Datenstruktur entwickelt werden. Zum
besseren Verständnis und Lesbarkeit wird in diesem Abschnitt die PAVONE ProcessModeller XML-Datei auf einen Baum abgebildet (siehe Abbildung 5.14). Die Analyse des
Baumes wird nun im Folgenden Abschnitt eingeführt.
PAVONEProcessDefinition
<PAVONEProcessDefinition>
<PDGeneral>...</PDGeneral>
<ActivityDefinitions>...</ActivityDefinitions>
<PAVONEProcessDefinition>
PDGeneral
ActivityDefinitions
Bild 5.14: Abbildung der PAVONE-Prozessdefinitionsdatei auf einen Baum
Der Baum besteht aus zwei Hauptteilbaumen: dem allgemeine Einstellungen Teilbaum
(PDGeneral) und dem ActivityDefinitions-Teilbaum.
Allgemeine Einstellungen Teilbaum (PDGeneral)
PDGeneral-Teilbaum enthält allgemeine Einstellungen, wobei die Struktur dieses Teilbaumes starr und genau vorgegeben ist. Somit ist die Position der einzelnen Einstellungen
genau bekannt und kann direkt ausgelesen und auf die interne Programmstruktur abgebildet werden. (siehe Abbildung 5.15)
PDGeneral
PDBasic
ProcessDefinitionID
Arno Rautman(2010-03-22 14:57:38)
Bild 5.15: Teilbaum für allgemeine Einstellungen
5 Kontept/Architektur des Business Process Modeler
67
Activity Definition-Teilbaum (PDGeneral)
Im Gegensatz zum Teilbaum “Allgemeinen Einstellungen” wird der Inhalt dieses Baumes
dynamisch gefüllt, wobei ein Teilbaum dieses Baumes genau ein Aktivitäten Element
enthält. Der Aktivity Definitions Baum enthält zum Teil starre, zum Teil dynamische
Strukturen. Zum Beispiel kann der Zugriff auf den Namen der Aktivitat (siehe Abbildung
5.16) über den Pfad ActivityDefinition → ADBasic → Name erfolgen.
Dagegen wird in dem Pfad ActivityDefinition → ADBasic → ADLinks eine beliebige
Anzahl der Verbindungselemente gespeichert. Somit muss bei der Abbildung der Inhalte
die Struktur des Baumes berücksichtigt und eine Abbildung für starre und dynamische
Strukturen umgesetzt werden.
ActivityDefinition
ADBasic
Name
ADLinks
“Register Order“
ADLink
ADLink
Bild 5.16: Aktivitäten-Teilbaum
KERNEL
Beim Kernel Modul handelt es sich um die zentrale Instanz des Programms, welche die
Zusammenarbeit unterschiedlicher Module ermöglicht und koordiniert. Um einen einheitlichen Zugriff zu ermöglichen, ist es ratsam, dieses Modul auf eine einzige Klasse abzubilden. Im Folgenden werden Überlegungen zu den einzelnen Teilen der Kernel-Klasse
aufgestellt.
Universelle Schnittstelle Durch die BPMN Klassenbasierte Struktur ist eine Funktionalität gegeben, die BPMN Instanzen der unterschiedlichen Ausprägungen zu erzeugen und zu speichern. Die Speicherung der Elemente sollte möglichst in einer allgemein
zugänglichen Stelle in dem Softwaresystem erfolgen, um einen gemeinsamen Zugriff auf
5 Kontept/Architektur des Business Process Modeler
68
diese Elemente zu ermöglichen. Die zentrale allgemein zugängliche Stelle im System, die
vereinbart wurde, ist die Kernel-Klasse. Ein Datentyp, welcher die Speicherung von Objekten beliebiger Ausprägung erlaubt, ist ein Array vom Datentyp Objekt. Somit können die
im Softwaresystem vorhandenen Objekte in einem Array der Kernel-Klasse zur Verfügung
gestellt werden.
Schnittstelle zu Benutzeroberflächen Modul Wie bereits besprochen, muss die
Hauptzeichenfläche des Softwaresystems aus einer Canvas-Komponente bestehen. Als eine
der UI-Komponenten der Adobe Flex Entwicklungsumgebung implementiert Canvas die
updateDisplayList()-Methode, welche immer dann aufgerufen wird, wenn auf irgendeine
Art und Weise mit einer UI-Komponente interagiert wird (z.B. durch Maus und Tastatureingaben, Änderung der Komponentengröße u.s.w.). Diese Komponente kann überschrieben und mit eigenem Inhalt gefüllt werden. Auf diese Weise kann die Routine zum
Zeichnen sämtlicher Grafik umgesetzt werden. Dies kann in eigene Methode ausgelagert
werden. Da die sämtlichen Elemente außer der Menüstruktur gezeichnet werden, bietet
sich folgender Ablauf an:
• Zeichne die Objekte der BPMN-Notation
• Zeichne das Akkordeonobjekt
• Zeichne das Aktionsleistenobjekt
Oberflächenzustandsautomat
Durch manche Aktionen wie z.B. die Aktivierung des Lasso-Elements oder durch Umschaltung in den Verbindungsmodus muss das Softwaresystem auf bestimmte Eingaben unterschiedlich reagieren. Dieses Verhalten kann mittels eines Zustandsautomaten modelliert
und innerhalb des Kernels umgesetzt werden. Für das Lasso kann dieser Zustandsautomat auf folgende Art und Weise definiert werden. Als Startzustand wird Standardmodus
der Benutzeroberfläche definiert. Im Standardmodus befindet sich das Softwaresystem
genau dann, wenn keine “speziellen” Aktionen (Lassoaktionen, Elementverbindungsaktionen) ausgeführt werden. Wird nun eine Stelle der Benutzeroberfläche angeklickt, die
keine BPMN enthält, und wird mit der gedrückten Maustaste eine Bewegung ausgeführt,
so wird diese Reihenfolge als ein Wunsch interpretiert, die Lassofunktionalität zu aktivieren. An dieser Stelle schaltet der Kernel in einen Zustand, welcher das Lassoobjekt
aktiviert und die Mausaktionen auf die Koordinaten des Lassoobjekts abbildet.
5 Kontept/Architektur des Business Process Modeler
69
Standard Mode
[switch to lasso mode]
[switch to standard mode]
Lasso Mode
do/listen if elements captured
[switch to standard mode]
[switch to lasso elements captured mode]
Lasso Elements Captured
do/listen if selected elements to be moved
[switch to move captured lasso elements mode]
Move Lasso Captured Elements
do/move captured elements
Bild 5.17: Zustandsautomat bei Aktivierung und Verwendung des Lasso Elements
Beschreibung eines Anwendungsfalls
Im Folgenden wird ein mögliches Szenario bei den Anwendungen mit der aktuellen Version
des Prototyps aus der Benutzersicht beschrieben. Eine Vorrausetzung für dieses Szenario
ist die Existenz einer lokal gespeicherten Version einer PAVONE ProcessModeler XML
Ausführungsdatei. Der Benutzer startet einen Browser und gibt die URL des Prototyps
ein. Nachdem die Software gestartet wurde, kann der Benutzer über einen Menüaufruf
die PAVONE ProcessModeler XML Ausführungsdatei öffnen. Hierdurch wird die in der
XML-Datei gespeicherte Struktur geladen und auf der Oberfläche des Softwaresystems
dargestellt.
Durch einen Menüaufruf kann ein Dialog für allgemeine Einstellungen gestartet werden.
Die Einstellungen können nun manipuliert und mittels einer Bestatigung (via “OK”Button) von dem System übernommen werden.
Durch jeweils einen Doppelklick auf eine Aktivität oder einen Verbindungspfeil können die
Dialogboxen mit erweiterten Einstellungen dieser Elemente angesehen und gegebenenfalls
geändert werden. Die graphischen Elemente können auf der Benutzeroberfläche auf andere
Koordinaten verschoben werden. Durch die Selektion einer Aktivität kann deren Name
mittels der direkten Tastatureingabe geändert werden.
Der Benutzer kann nun mittels eines Menüaufrufes eine Speicherroutine starten. Dem
5 Kontept/Architektur des Business Process Modeler
Bild 5.18: Geladener Geschäftsablauf
Bild 5.19: allgemeine Einstellungen Dialog
70
5 Kontept/Architektur des Business Process Modeler
71
Bild 5.20: Direkte Tastatureingabe auf einem Aktivitaten Element
Benutzer wird angeboten, die Stelle in dem Dateisystem zu wählen, wo die gespeicherte
Datei abzulegen ist.
Der Benutzer könnte nun die XML-Ausführungsdatei mit der lokalen installierten lokalen
Version des PAVONE ProcessModellers öffnen und die erweiterten Möglichkeiten (wie
zum Beispiel Simulation) dieses Werkzeugs nutzen.
Bild 5.21: PAVONE ProcessModeler
Die XML-Ausführungsdatei kann innerhalb der beiden Anwendungen bearbeitet und zwischen diesen beliebig ausgetauscht werden.
5.3
Fazit
In diesem Kapitel wurden Konzepte und Methoden für die Umsetzung des Prototyps einer
Rich Internet Application zur Modellierung von Geschäftsprozessen basierend auf BPMN
entwickelt und beschrieben. Hierfür wurde ein klassisches Wasserfallmodell verwendet,
es wurden Anforderungen an das Softwaresystem definiert, die Einsatzumgebung analysiert und, auf diesen Erkenntnissen basierend, die Systemarchitektur entwickelt. Weitere
Detaillierung erfolgte im Grobentwurf, wo das System in Module aufgeteilt wurde. Zum
5 Kontept/Architektur des Business Process Modeler
72
Schluß fand eine Verfeinerung der Module und deren Abbildung auf die einzelnen Klassen
statt.
Ein mögliches Szenario für die Einbindung des Modeleres ist die Einbindung innerhalb
PAVONE Live Umgebung1 . Momentan können in der PAVONE Live Umgebung Prozessdefinitionen mittels eines Formulars angelegt werden. Da es aber erwünscht ist, die
Einbindung durch Modellierungswerkzeug durchzuführen, wäre es an dieser Stelle von
Vorteil, die entsprechende Komponente der in dieser Arbeit entwickelten Anwendung in
PAVONE Live Umgebung zu integrieren. Ein mögliches Aussehen eines solchen Szenarios
ist in der Abbildung 5.22 zu sehen.
Bild 5.22: Mögliches Einbindungsszenario des Modelers innerhalb der PAVONE Live
Umgebung
1
http://www.pavonelive.pavone.de
Kapitel 6
Zusammenfassung und Ausblick
In dieser Arbeit wurde die Anwendung einer Rich Internet Application zur Modellierung
von Geschäftsprozessen untersucht. Die Zielsetzung war, die bestehenden Technologien
zur Modellierung und Ausführung der Geschäftsprozesse in einer Software zu analysieren und zu vergleichen und die Konzepte des BPMN-Modellierung-Standards in einem
Geschäftsprozessmodellierungstool zu implementieren. Dabei wurde das Tool als eine Rich
Internet Application konzipiert und prototypisch umgesetzt.
Im Rahmen der Arbeit wurde Fachliteratur zu den Themen visuelle Sprachen zur Modellierung von Geschäftsprozessen und Ausführungssprachen studiert und die Konzepte und
Methoden untersucht, die in diesen Gebieten Verwendung finden. Es wurden Verfahren
zur Erzeugung einer Rich Internet Applikation erforscht und in Bezug auf die gestellte
Aufgabe - Umsetzung des Business Process Modeler verglichen. Nach den Literaturrecherchen wurde die Entwicklungsumgebung Adobe Flex gewählt, um eine benutzerfreundliche
Umsetzung zu gewährleisten.
Das entwickelte Werkzeug zur Modellierung von Geschäftsabläufen ist vollständig in einem Webbrowser nutzbar, ohne dass eine Installation auf der lokalen Festplatte des Benutzers erforderlich ist. Dabei wurde darauf geachtet, dass der Programmcode gut wartbar
und erweiterbar sein sollte. Durch die Verwendung einer strikt objekt-orientierten Vorgehensweise bei der Umsetzung des Softwaresystems kann diese Zielsetzung als erreicht
betrachtet werden. Gute Wartbarkeit wurde durch die strikte Trennung und Wiederverwendung der einzelnen Funktionalitäten erreicht. Erweiterbarkeit ist durch die Klassenstruktur gewährleistet. So können zum Beispiel die zusätzlichen BPMN-Elemente auf eine
einfache Art und Weise der Datenstruktur hinzugefügt werden, indem die gruppenspezifischen Eigenschaften jeweils von der Gruppenoberklasse geerbt werden. Verwendung eines
Benutzeroberflächenzustandsautomaten ermöglicht es, weitere benutzeroberflächenspezifische Elemente problemlos hinzuzufügen.
6 Zusammenfassung und Ausblick
74
Für den Benutzer sollte das Softwaresystem benutzerfreundlich und schnell sein. Benutzerfreundlichkeit wurde erreicht, indem die meisten Aktionen mittels eines Mauseklicks
oder mittels eines Drag & Drop - Verfahrens ausgeführt werden können. Die Performanz
wurde durch die Verwendung einer Reihe von Verfahren und Algorithmen, die bei der
Entwicklung des Werkzeugs umgesetzt wurden, erreicht.
Einer der Aspekte bei der Umsetzung des Werkzeugs war die Abbildung auf die
Ausführungssprachen. In dem in der Arbeit erreichten Stand des Werkzeugs wird die
Abbildung auf die Ausführungssprache von PAVONE ProcessModeler unterstützt, in Zukunft sind auch Erweiterungen auf BPEL und XPDL möglich.
Die bei der Umsetzung des Prototyps verwendete Vorgehensweise ermöglicht eine Umsetzung des Prototyps für mobile Geräte, was zum Gegenstand weiterer Entwicklung werden
könnte.
Insgesamt können die Ziele der Diplomarbeit als erreicht betrachtet werden.
Anhang A
Hinweise zur beigelegten CD
Der Diplomarbeit ist eine CD beigelegt, auf welcher sich die aktuelle Version des Prototyps befindet (Stand 22.03.2010). Der Prototyp kann im Verzeichnis ’Prototyp’ durch
Öffnen der Datei ’index.html’ gestartet werden. Allerdings stehen dann keine ’Öffnen’
und ’Speichern’-Funktionen zur Verfügung. Hierfür muss eine lokale Version eines JSP
unterstützenden Web-Servers (z.B. JBoss) gestartet werden. In diesem Fall kann der Prototyp mittels eines URL-Aufrufs (http://localhost:8080/ProcessModeler.html) in einem
Browser gestartet werden.
Im Verzeichnis ’ProzessDefinitionen’ befinden sich Beispielsdateien der Prozessabläufe,
die geladen und bearbeitet werden können.
Im Verzeichnis ’Diplomausarbeitung’ bifindet sich die finale Version der Diplomausarbeitung im PDF und PS Format.
Um den Quellcode anzusehen, muss die aktuelle Version des Adobe Flex Builders installiert sein. (Kann von der Herstellerseite unter https://www.adobe.com/ geladen werden.)
Innerhalb des Adobe Flex Builders kann mittels eines Menüaufrufes (File→Import→Flex
Project...→Archive file) eine Datei importiert werden, welche sich im Verzeichnis ’Prozessmodeler’ befindet. Hierdurch wird der aktuelle Stand des Projekts in den Flex Builder
geladen.
Anhang B
Tabelle der Werkzeuge zur
Geschäftsprozessmodellierung
Legende: ⊙ - Notation unterstützt, • - Standardnotation
B Tabelle der Werkzeuge zur Geschäftsprozessmodellierung
77
Binner IMS
BOC
Dr. Lürzer
EMPRISE
Get Process
IDS Scheer
IMG / S&T
intellior
ADONIS
promol.NET
BONAPART
Income Suite
ARIS Plattform
SemTalk/Prome@work
AENEIS
Produkt
sycat
Anbieter
Agresso Business Modeller Agresso
Tabelle B.1: Werkzeuge und unterstützte Modellierungssprachen
Geschäftsprozessmodellierungssprache
- UML
⊙
- BPMN
⊙
- BPEL
⊙
- IUM
⊙
⊙
⊙
- LOVEM
⊙
•
⊙
⊙
⊙
⊙
⊙
•
- EPK
•
- SOM
⊙
- KSA
⊙
- Flowchart
⊙
•
- Ishikawa
Eigene Notation implementieren
•
⊙
•
⊙
•
•
•
⊙
⊙
•
⊙
⊙
⊙
•
•
⊙
⊙
•
⊙
- Sonstige
Selbstdefinierte Objektbibliothek
⊙
•
•
•
⊙
⊙
•
⊙
•
•
⊙
•
•
•
•
•
•
•
•
•
•
•
B Tabelle der Werkzeuge zur Geschäftsprozessmodellierung
Semtation
Soreco
ViCon
SemTalk
Xpert.ivy
ViFlow
MID
Innovator
pulinco
MEGA
MEGA Process
Anbieter
TopEASE
IPK
Mo2 GO
Espresso Workflow PAVONE
inubit
inubit
Tabelle B.2: Werkzeuge und unterstützte Modellierungssprachen. Fortsetzung.
Produkt
Geschäftsprozessmodellierungssprache
⊙
⊙
•
⊙
⊙
⊙
•
•
•
•
- UML
⊙
•
•
⊙
⊙
⊙
•
- BPEL
•
- IUM
•
- LOVEM
•
•
- EPK
⊙
⊙
⊙
⊙
⊙
•
- SOM
⊙
•
•
•
- KSA
⊙
•
⊙
•
- Flowchart
- Ishikawa
•
•
- BPMN
•
•
•
•
•
•
⊙
⊙
- Sonstige
•
•
Selbstdefinierte Objektbibliothek
•
•
Eigene Notation implementieren
78
Literaturverzeichnis
[ACD+ 03] T. Andrews, F. Curbera, H. Dholakia, Y. Goland, J. Klein, F. Leymann,
K. Liu, D. Roller, D. Smith, S. Thatte, I. Trickovic, and S. Weerawarana.
Business Process Execution Language for Web Services, Version 1.1. BEA
Systems, IBM International Business Machines Corporation, Microsoft Corporation, SAP AG, Siebel Systems, 2003.
[Ark02] Assif Arkan. Business Process Modeling Language. Business Process Management Initiative, 2002.
[Bal93] H. Balzert. CASE, Systeme und Werkzeuge. 1993.
[BE] Heide
Brücher
and
Rainer
Endl.
Erweiterung
geschäftsregelorientierten Prozessmodellierung.
von
UML
zur
Technical report, Uni-
versität Bern, Institut für Wirtschaftsinformatik, Engehaldenstrasse 8,
CH-3012 Bern, Switzerland.
[CKM+ 09] Luc Clement, Dieter König, Vinkesh Mehta, Ralf Mueller, Ravi Rangaswamy, Michael Rowley, and Ivana Trickovic. WS-BPEL Extension for People
(BPEL4People) Specification Version 1.1. OASIS, 2009.
[DKKZ08] Jens Drawehn, Florian Kicherer, Dietmar Kopperger, and Daniel Zähringer.
Process Management Tools 2008. Eine evaluierende Marktstudie zu aktuellen
Werkzeugen. Fraunhofer IRB Verlag, 2008.
[FGI+ ] A. Filograna, G. Giunta, N. Ingraffia, L. Loiacono, and D. ZA A. Corallo. An
integrated approach for modelling business processes using bpmn and xpdl
standards. Technical report, Engineering Ingegneria Informatica S.p.A., R&D
Lab, Palermo,90100, Italy.
[Fro10] Ingo
Frommholz.
Prozessmodellierung
mit
petri-netzen.
http://www.is.inf.uni-due.de/courses/ie ss07/folien/folien-prozesse.pdf,
am 20.03.2010.
unter
LITERATURVERZEICHNIS
80
[Hei09] Martin Heinzerling. Vergleich von prozessbeschreibungssprachen: Bpel vs.
xpdl vs. jpdl, 2009.
[HKM] Thomas Hornung, Agnes Koschmider, and Jan Mendling. Integration of heterogeneous bpm schemas: The case of xpdl and bpel. Technical report, Institute
of Computer Science, Albert-Ludwigs University Freiburg, Germany, Institute
of Applied Informatics and Formal Description Methods University of Karlsruhe (TH), Germany, Institute of Information Systems and New Media, WU
Vienna, Austria.
[JK09] Kurt Jensen and Lars M. Kristensen. Coloured petri nets. Springer, 2009.
[KL08] Chafic Kazoun and Joey Lott. Programming Flex 3. O’Reilly, 2008.
[Lau10] Prof. Dr. Georg Lausen. Petri-netze. unter http://electures.informatik.unifreiburg.de/lectures/db fgis/2007-2008ws/slides/3-1-petrinetze 4up.pdf,
am
20.03.2010.
[omg09] Business Process Model and Notation (BPMN). Object Management Group,
2009.
[OWS+ 03] Bernd Oestereich, Christian Weiss, Claudia Schröder, Tim Weilkiens, and
Alexander Lenhard. Objektorientierte Geschäftsprozessmodellierung mit der
UML. dpunkt.verlag GmbH, 2003.
[pre10] Bpmn-spezifikation version 1.2. unter http://www.omg.org/spec/bpmn/1.2/pdf,
am 20.03.2010.
[Rüc08] Bernd Rücker. Welche Sprache spricht BPM? JavaSPEKTRUM, Ausgabe:
April 2008.
[RO03] Jog Roj and Martin Owen. BPMN and Business Process Management. Popkin
Software, 2003.
[Sch08] Ina Schieferdecker. Model driven architecture - foundations and applications.
Fraunhofer IRB Verlag, 2008.
[vdA] W.M.P. van der Aalst. The application of petri nets to workflow management.
Technical report, Eindhoven University of Technology, Department of Mathematics and Computing Science, P.O. Box 513, NL-5600 MB, Eindhoven, The
Netherlands.
LITERATURVERZEICHNIS
81
[Wal08] Hans-Dirk Walter. Rich Internet Applications. Eine perfekte Kombination benutzerfreundlicher Schnittstellen mit Webtechnologie. Informatik-Spektrum,
pages 333–343, 2008.
[Whi04a] Stephen A. White. Introduction to BPMN. IBM, 2004.
[Whi04b] Stephen A. White. Workflow Patterns with BPMN und UML. IBM, 2004.
[Whi05] Stephen A. White. Using BPMN to model a BPEL Process. IBM, 2005.
[Whi06] Stephen A. White. Process Modeling Notations and Workflow Patterns. IBM,
2006.

Zugehörige Unterlagen

1. ¨Ubungsprojekt Verkaufszahlen Bericht mit Drill Down Funktion

Inhaltsverz 7..10

Diplomarbeit Konzeption und prototypische Implementation einer

Zugehörige Unterlagen

Dieses Dokument Sammlung (en)

Dieses Dokument gespeichert

Schlagen Sie uns vor, wie wir StudyLib verbessern können